10 ms·
Age: A simple, modern and secure file encryption tool
- todotask 7y agoIs age designed to encrypt large binary files, which seem to increase the file size by 2KB.
- str4d 7y agoYes. age encrypts large files in 64 kiB chunks with 16 bytes of overhead per chunk, which strikes a balance between file size overhead and performance (particularly when seeking).
- todotask 7y agoThat's interesting and seem to be an alternative to encrypted zip or 7z which could be used in productions?
- est31 7y agoRust implementation: https://github.com/str4d/rage https://github.com/str4d/rage
- AgentME 7y agoOoh, the included "rage-mount" utility allows mounting an age-encrypted zip or tar file as a directory. (It can be installed with `cargo install --features mount age`.)
- Kovah 7y agoAge looks somewhat promising, but I am still looking for a reasonable alternative to TrueCrypt. Encryption should be as easy as possible. The process of gathering your files (plural!), put them into a folder, zip or tar that folder and then encrypt it, to delete the remaining files afterwards, is anything but not easy. Adding new files is even more horrible. TrueCrypt was so easy, just select the encrypted file, enter your password and voila, you got a volume mounted where you can easily add or remove many files. I know that Veracrypt exists, but it does not feel like a solution for the next decade(s). Its super weird. There is this use case to de/encrypt a single file, but mass storage of files in a secure way and without a proprietary protocol seems impossible.
- ReptileMan 7y agoYou mean like VeraCrypt?
- GordonS 7y agoI've been using VeraCrypt for a few years now, and have nothing bad to say about the experience - it's really easy to setup and operate.
- TeddyDD 7y agoThere are nice solutions on Linux: luks (encrypting partitions) and cryfs (encrypting directories)
- globular-toast 7y agoNo good without plausible deniability. It was that feature that got Truecrypt in trouble.
- dependenttypes 7y ago> and cryfs (encrypting directories) Pretty sure that this leaks a lot of metadata.
- eikenberry 7y agoThere is also gocryptfs. It is written by some of the same people who did encfs and attempts to fix all the security issues discovered during its years of use. https://github.com/rfjakob/gocryptfs https://github.com/rfjakob/gocryptfs
- 999gold 7y agorclone does that, you can mount an encrypted folder as a disc...
- Boulth 7y ago> Out of scope: > The web of trust, or key distribution really Is there anything in the tptacek suite of replacement tools for this? Like Keybase but fully open source and/or decentralized?
- nmadden 7y agoIs there a detailed description of the security goals and crypto rationale anywhere? For example, it seems that if you use scrypt then you get fully authenticated encryption: the message must have come from somebody who knows the password (either a trusted user or you chose a weak password). But if you use X25519 then the scheme used is ECIES, so no sender authentication, only IND-CCA security. The format document says that if you want “signing“ then use minisign/signify, but I suspect most people want origin authentication. We know that it is actually quite hard to obtain public key authenticated encryption [1] from generic composition of signatures and encryption, with many subtle details. It would be better if age supported this directly for X25519 as it does for scrypt. Unfortunately, you can’t simply use a static key pair to achieve this (as in nacl’s box) as age uses a zero nonce to encrypt the file key with chacha20-poly1305 so reusing a static key will result in nonce reuse. (This seems a bit fragile). [1]: https://eprint.iacr.org/2001/079 https://eprint.iacr.org/2001/079
- nmadden 7y agoAn example of why I think this is important. Adam Langley’s post that is linked from the spec [1] talks about cases where people want to do things like: decrypt file | tar xz Elsewhere in these comments somebody also mentioned the case of decrypt file | sh Presumably the whole point of implementing the STREAM online AEAD mode is to support these kinds of cases; only releasing chunks of plaintext after verification. But these use-cases are only secure in age when using the scrypt decryption option or if you have first verified a signature over the entire age-encrypted archive (killing the streaming use-case). The reason is that the X25519 age variant provides no sender authentication at all, and so an attacker doesn’t need to tamper with the archive: they can just generate their own ephemeral key pair and replace the entire thing with data of their choosing. Age has no way of detecting such an attack. You absolutely need origin/sender authentication built directly into the tool to handle these cases securely. [1]: https://www.imperialviolet.org/2014/06/27/streamingencryption.html https://www.imperialviolet.org/2014/06/27/streamingencryptio...
- nmadden 7y agoI wrote up some more detailed notes here: https://neilmadden.blog/2019/12/30/a-few-comments-on-age/ https://neilmadden.blog/2019/12/30/a-few-comments-on-age/
- cies 7y agoA tool/protocol is as secure as the people using it. I found that when working with non-techies that 7Zip is an acceptable encryption tool. It used proper encryption, it's open source, available on all platforms, available with GUI and CLI.
- deleted 7y ago[deleted]
- john_alan 7y agoWhich crypto primitives does this tool use? x25519+chacha?
- dependenttypes 7y ago+ poly1305 + scrypt
- joshbaptiste 7y agoI normally use scrypt (with passphrase) for file encryption for personal backups.. age isn't competing with this use case i take it?
- tialaramex 7y ago"it looks like we'll be ok" remains their status on the problem of whether it's fine to just take SSH keys and use them for something quite different. That's just not good enough. It was fine in early drafts because there was hope they'd remember that "Solve all of the world's problems" was not their goal, and so SSH keys might be irrelevant in later revisions anyway. It's not fine in something intended to actually ship. Either get somebody to put lots of work in to verify that yes, it's definitely safe to do this as SSH stands today, and contact SecSH WG or Sec Dispatch or whoever to make sure they know you're doing this now - or, as seems much more likely, rip out all the SSH key code and highlight that line about how you don't want to do key distribution in age because it's hard. PGP is full of things its creators thought might be safe that you now have to tell people not to do because it turns out they're unsafe. This tool should not recapitulate their mistake.
- FiloSottile 7y agoI am fairly confident the SSH key reuse is fine, or I wouldn't have shipped it. But yes, it would be a misrepresentation to say there are formal proofs of it. There's no one I can think of that we can pay in short order to make robust ones. FWIW, we don't really have proofs for ECDSA either, and it's been almost 30 years. (Anyway, the core age flow with native keys is unaffected.)
- CodesInChaos 7y agoSome questions about the spec: 1. How does age disambiguate between filenames and other key formats for the -r argument? (Those formats are also valid filenames) 2. Does the header use normal Base64 (i.e. +/) or url-safe Base64 (i.e. -_). The specification sounds like normal Base64, but some lines of the example contain -_ others contain +. 3. What characters are allowed in the header? ASCII only? (the current key-formats are ASCII only, but an implementation is supposed to skip unknown formats) 4. Are any characters forbidden in recipient types, arguments and additional lines? 5. Which strings at the beginning of a header line have special meaning and thus are illegal for additional lines? Only `-> ` and `--- `? I assume the space is mandatory in those strings despite the spec not mentioning that for `->`? 6. CRLF normalization of the header is only mentioned in the section about ascii-armored files. I assume it also applies to non ASCII armored files? 7. Is keeping the public key secret to achieve symmetric authenticated encryption an officially supported/recommended use-case? (If the public key is public, the MACs block decryption oracles. However they don't provide any authentication, because the message isn't bound to any sender and thus an attacker can just encrypt their own message to your public key. If the receiver's public key is secret, this isn't possible and thus the current implementation provides symmetric sender authentication) 8. How does the command line tool signal failure/truncation/corruption?
- str4d 7y agoAnswering what I can. Where something is an implementation detail, I'm referring to rage (which I'm obviously more familiar with). 1. rage tests arguments for validity as filepaths, and uses the file preferentially over treating the argument itself as a recipient format. 2. The header uses normal Base64. This was changed recently, and the examples likely need updating. 3. rage currently rejects unknown formats; I haven't implemented this part of the spec yet. 4. Based on the current contents of the age specification, it looks like limiting to standard Base64 characters is consistent. 5. Additional lines all need to be standard Base64 characters (i.e. consistent with the format of current recipient lines) if implementations are going to be able to skip unknown formats. (Recipient lines are currently under-specified in the spec. I opened https://github.com/FiloSottile/age/issues/9 https://github.com/FiloSottile/age/issues/9 a while back for addressing this.) 6. The normalization notes are an artifact of an earlier ASCII armoring format. Now that the armor is (a strict subset of) PEM, there is no need for CRLF normalization, as the age format solely uses LF, and PEM (which can tolerate either) is only a wrapper around the age format and thus does not affect the header. 8. rage signals this via an I/O error in the library that will bubble up through std::io::copy; this amounts to truncation on a chunk boundary and a non-zero exit value.
- stutonk 7y agoI once made something similar after reading a blog post here on HN [1] just to see how easy it is to make something like this. Mine [2] uses passphrases to generate keys with the Argon2 algorithm and then uses NaCl's secretbox for encryption. I also made a version for use on streams. It's not up to snuff for industrial use, but it's really easy to use if you just want to encrypt some files with a password and also very simple if you want to modify it for your own purposes. [1] https://blog.gtank.cc/modern-alternatives-to-pgp/ https://blog.gtank.cc/modern-alternatives-to-pgp/ [2] https://stutonk.github.io/crypt.html https://stutonk.github.io/crypt.html
- _paulc 7y agoThis looks really good, I've used ccrypt (#1) for years as a simple Unix-y encryption tool to avoid the complexity of GPG (though this is symmetric encryption only so you need to have a secure way to exchange keys). I just added a pull-request to allow the recipients flag to also be specified as a https:// https:// or file:// URL - this is mostly useful to use the GitHub <user>.keys endpoint to grab user keys eg. ./age -a -r https://github.com/<user>.keys < secret will encrypt using <user>'s GitHub SSH public keys. #1 http://ccrypt.sourceforge.net http://ccrypt.sourceforge.net #2 https://github.com/FiloSottile/age/pull/43 https://github.com/FiloSottile/age/pull/43
- labawi 7y agoSo.. this is using chunked AEAD, without source authentication/signing? What's the actual use case, and why is it any better than plain stream encryption? If you wish to stream authenticated decrypted contents, it would mean 2 layers of chunking.
- lilyball 7y agoWhat problem is this solving that isn't already done by other tools?
- tptacek 7y agoThis is like the engine underneath PGP, but modernized and with the misfeatures stripped out. You'd use it, instead of PGP (which is bad) for encrypting files, and as a building block for the operational tools that really are just straightforwardly encrypting files (ie: not messaging, which has its own distinct needs and has purpose-built cryptosystems for). More on this: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
- tzs 7y agoFrom the linked blog: > A Swiss Army knife does a bunch of things, all of them poorly. Counterexample: the Phillips head screwdriver in my Swiss Army knife is actually the best Phillips head I've ever found. It can easily turn without slipping a wider range of screw head diameters and depths than any other screwdriver I've used. (Does anyone else have way more screwdrivers around than they can explain? I cannot think of any reason I would own more than two or three full sized screw drivers, and one set of small of jewelers screwdrivers...but I've got more than a dozen full sized ones and a couple sets of jewelers screwdrivers. I cannot remember buying, inheriting, finding, stealing, borrowing and not returning, or being gifted any of them--but there they are. Glitch in the matrix?)
- xxs 7y agoOne thing about the Phillips screw driver - perhaps it's Pozidriv[0] type, that's compatible with Phillips but different/better. "Phillips" was originally designed to slip to prevent over-tighten. One more PH. screwdrivers come in various sizes (read the listed article for more). Using the correct one works significantly better for: flat/ph/pz, etc. For stuff like torx is not even possible to use incorrect screwdriver. Last screwdriver quality greatly varies, with some brands being exceptionally expensive or even pride material to own. [0]: https://en.wikipedia.org/wiki/List_of_screw_drives#Pozidriv https://en.wikipedia.org/wiki/List_of_screw_drives#Pozidriv
- TedDoesntTalk 7y agomeh. https://stackoverflow.com/questions/16056135/how-to-use-openssl-to-encrypt-decrypt-files/16056298#16056298 https://stackoverflow.com/questions/16056135/how-to-use-open... With that I'm guaranteed AES, a known-good encryption algorithm. I have no idea what these guys are doing without reading through their documentation. Hopefully they didn't roll their own.
- Natanael_L 7y agoWhat you're linking has now literally been edited with an update to suggest the tool age. The idea that "AES is enough" is like saying you don't need better winter clothes to go skiing because you have a good helmet. There's still more things left you need to protect than that! A secure block cipher mode and key management and IV generation, etc, is mandatory!
- tptacek 7y agoThat command line doesn't even produce authenticated ciphertext. I'm amazed that's the check-marked best answer on Stack Overflow.
- wolf550e 7y agoI have seen many questions on security stack exchange and /r/crypto where the correct answer should have been "use age", but because it didn't exist the correct answer was something bad. openssl CLI is not meant to be used in prod (both because not AEAD and because the man page tells you not to use it). gpg is bad. rolling your own CLI tool using libsodium is not for everyone.
- tptacek 7y agohttps://twitter.com/pwnallthethings/status/1210735552535752705 https://twitter.com/pwnallthethings/status/12107355525357527... I'd be nicer but for the "hopefully they didn't roll their own" at the end.
- TedDoesntTalk 7y ago
- kick 7y agoNot that it matters, but age hasn't hit 1.0 yet. (Close, though!) With that in mind, it's still really exciting. I can't wait until I never have to use GPG ever, ever again.
- hnews_account_1 7y agoCan I ask a question that I've never been able to answer by Googling? Kleopatra is the tool of choice for GUI based GPG / PGP stuff on Windows right? So why is it that literally any software I download, it cannot locate the keys on any online database including MIT and whatever else are the top keystores online. If those keystores are not being regularly updated by trusted data vendors, how am I supposed to trust Gpg signed stuff? It isn't like SHA where I just need to compare 2 hashes. I'd shift to command line tools if I knew that the protocol was being widely used effectively.
- deleted 7y ago[deleted]
- AgentME 7y agoNot everyone uploads their PGP keys to keyservers. Also, keyservers don't verify the ownership of the keys uploaded to them. You're supposed to import the signer's public key first.
- aasasd 7y agoA nice example is the number and names of keys for <president@whitehouse.gov>.
- hnews_account_1 7y agoYes that's the other choice right? But then if I'm going to a compromised website with no idea that a MITM attack is taking place, I'd download the wrong public key wouldn't I? In that scenario, why is it trusted more than something much simpler like SHA? Is it just because it doesn't need a hash calculation? So the larger question is, how do I verify ownership of a medium level distributed file? Like not tens of millions of users who host mirrors etc so that everything is cross checkable. But not like a 10 downloads a month software either.
- ur-whale 7y agoThis is neat. A quick browse through the code, looks like it uses DJB's chacha and polyxxx underneath. I've been waiting for a worthy replacement for "crypt" for a very long time, and gpg, while it can be coaxed into doing that with much effort has simply become a bloated abomination at this point. Hope this gets vetted by the crypto community and gains popularity.
- tptacek 7y agoNot that I disagree but just a quick note that Filippo is very much a part of the cryptographic community.
- galaxyLogic 7y agoHow can we know there's no backdoor in it?
- baby 7y agoI don’t think it’s a bad question and don’t see why this is being downvoted. Security can only scale via one’s network, and if you don’t have any it can be hard to figure out what’s secure and what’s not! FWIW a little googling and you can see that filippo is pretty well known in the security/crypto community for positive contributions, same goes on for tqbf who’s all over this thread endorsing the tool. I would also trust the thing without looking at it, but I might take a look at the code someday to see what’s going on :)
- yellow_lead 7y agoIt seems you can read the source code?
- pknopf 7y agoIt's OSS?
- coldtea 7y agoYeah. So all you need is a 10+ year experience in crypto algorithms and weeks of close inspection of the code to verify it!
- smrq 7y agoSooo you need to trust someone that does have that experience to do the verification. What alternative are you suggesting? Is there some cool way to write your crypto so that a layman can successfully verify the integrity of a binary?
- galaxyLogic 7y ago> What alternative are you suggesting? One solution might be if some big corporation or even a government, or why not Bill Gates himself, offered a big ongoing bug-bounty for this Open Source Software.
- tedunangst 7y agoFinally! :)
- nullc 7y agoNSA recommended people stop using ECC <384 bits (https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa...). There are applications where the extra time and space of something like ed448 present uncomfortable trade-offs. File encryption is not generally one of those applications. So I find this a little disappointing. But I suppose that NIST PQ will finalize in the not far future and this will get replaced by something that hybridizes with a PQ scheme. (I say replace because the expectation that a pubkey is something you can easily copy and paste doesn't really work with the PQ schemes you'd likely use with file encryption.) What happens if auth fails part way through the file? Do you get a truncated decryption on stdout? -- or is this buffering the whole input in memory?
- CiPHPerCoder 7y ago> NSA recommended people stop using ECC <384 bits Since when does anyone care about NSA's opinion (who also don't have to care about FIPS compliance)?
- nullc 7y agoAnswering my own question: The reason it would continue to use 255 bit ECC is because an objective is (ab)using people's github ssh authentication keys. FWIW, if the idea there is that you'll be able to send encrypted reports to github users based on their ssh keys... that might not work so well in the long run esp for security conscious projects, since good practice would have their github ssh key living in a keyfob that won't decrypt messages for them. :)
- FiloSottile 7y agoNative age keys are pure X25519 with no connection to SSH keys. SSH support is kind of a growth hack, I made sure it didn't impact the rest of the design. Recipient types are the one parameterized thing in the spec, so if we need to switch to Ed448 or a PQ hybrid at some point we absolutely can, without even bumping the version.
- jiofih 7y agoI was ready to use this in a project but “made encryption weaker because GitHub” is not exactly high in its selling points
- zodiakzz 7y agoFor encrypting text files, I just use vim's `:X` command and enter a pass phrase. Simple, easy, portable, works everywhere. I have configured my .vimrc to `set cryptmethod=blowfish2` and disable backup/swap files for encrypted files. Are there any issues with this? Is there any other option that will work on virtually all UNIX devices without installing anything additional?
- tptacek 7y agoIt's so weird hearing what people are doing instead of PGP, and how bad it is. I had no idea vim even had this feature, but from what I've discovered in about 3 minutes of Googling, vim's "blowfish2" is the 64-bit-block Blowfish cipher in unauthenticated CFB mode. Just awful: Blowfish is weak, and attackers can manipulate the ciphertext of your files. This is why you want `age`.
- CiPHPerCoder 7y agoTrying to unfuck vim's encryption spawned a very interesting Github thread, if anyone is interested: https://github.com/vim/vim/issues/638 https://github.com/vim/vim/issues/638
- bscphil 7y agoThis is great, it fills a gap that I've long defended as PGP's remaining legitimate use case. Of course, now we just need to work on the adoption problem. Despite the fact that PGP adoption is a well-known joke in itself, all the tools designed to replace it (with the exception of the IM space) have somehow managed to achieve even lower use rates. It's been almost five years since Magic Wormhole first released, and about half a year since that popular Latacora post recommended it for transferring files, and said "Someone stick a Windows installer on a Go or Rust implementation of Magic Wormhole right away". Guess what you're still not going to find a reliable Windows build (let alone a GUI) for? Yep that's right. Despite the fact that most of these projects come from a felt need for better alternatives to PGP for the average user, very few of them have actually come up with a product that's more accessible to the average person.
- K2L8M11N2 7y agohttps://github.com/schollz/croc https://github.com/schollz/croc is written in Go, doesn’t need an installer and has worked reasonably well for me on Windows.
- psanford 7y agoThere's also https://github.com/psanford/wormhole-william https://github.com/psanford/wormhole-william. It's written in Go, doesn't need an installer and is compatible with the official wormhole client.
- badrabbit 7y agoWe need a protocol/scheme that other things can adopt much more than a tool. There will always be a reason why someone can't use a tool,but with an encoding/scheme/protocol you can push for different things to use it. To give an example, I was in a work situation more than once where an external party wanted to transfer files to or from our company and I was suppose to help find a standard tool/method. The only (and I mean only) way right now is pgp due to it's ubiquity with s/mime on email being second. We do need great tools like this but we need them to where if I can't use it due to license,policy,etc... Issues i can use a separate compatible tool. So, My only suggestion to the author is to please make a fixed and versioned standard out of the scheme.
- FiloSottile 7y agoYou'll be happy to know that the spec [0] existed even before the tool, and that there are already two implementations developed from the spec [1]! [0] https://age-encryption.org/v1 https://age-encryption.org/v1 [1] https://github.com/str4d/rage https://github.com/str4d/rage
- badrabbit 7y agoThank you, that's all my original comment was about. If the spec exists, I can for example write a client that works with it under a different license/language.
- tptacek 7y agoA protocol for what? To send messages securely? We have that. To do deduplicated mass backup? That exists, too. To securely transfer files? We have that as well. Each of these problems makes their own demands on cryptography and deserves their own purpose-built cryptosystem, which is why Signal looks like Signal, and not a naive message bus over which we push PGP-encrypted records. The point of `age` is that when you subtract out all these use cases from PGP and leave just the file encryption problem, PGP still sucks, and sucks way out of proportion to how complicated file encryption is. So instead of bringing all of PGP's bloat, 1990s cryptography, and misfeatures to bear on that simple problem, we just get a simple, modern tool optimized for that one problem.
- monoideism 7y agoSo the modern alternative would be this for file encryption, and signify for signing. What's the consensus on an alternative for GPG authenticating? And what are the expert opinions on themis: https://github.com/cossacklabs/themis https://github.com/cossacklabs/themis ?
- deleted 7y ago[deleted]
- tptacek 7y agoThemis looks like a more complicated take on libsodium, which is already the de facto standard modern crypto library. I'd use that instead.
- est31 7y agoI'm not a big fan of tools that take encrypted data, and decrypt it by creating a decrypted file on disk. They give you a false sense of security. Files, even if they get deleted, remain on hard disks. On SSDs they are even harder to remove, as there is a complicated layer of indirection. Even if you shred the file before deletion, it's possible that it will keep being stored by the SSD, maybe even permanently if a block containing the decrypted content is being decomissioned. The classical gpg based tools have this very same problem. The classical response is to suggest ramdisk usage, ideally for the entire OS (like a live system basically) to avoid getting artifacts onto the disk like clipboard history, cached thumbnails, or log files. pass for example uses such ramdisks. I disagree that this is a good solution though. Of course it is more thorough, but it requires additional intervention/setup, and not everyone has the needed expertise. Instead, I think the encryption tool itself should take care to only store the decrypted content in non-paged RAM, and give users read/write access through a GUI or a TUI. It should be a ready downloadable solution, similar to the TOR browser bundle. The TOR browser is also trying to not put anything onto the hard disk.
- nullc 7y agoThis tool is heavily setup to work with streams. However, if your disk is exposed -- lots of other things, including shell history, swap, etc. may give you away. The problem with stuff like "gives users read/write access" -- is that it presumes a narrow use case. What if you're encrypting digital audio? Source code? etc. Should it also turn on your mic and try to determine if you're in a room alone? :P Demand you use an anti-tempest font? There is only so much a tool can do. It's important that the tool does what it can within the context that it'll be used, but beyond that the best it can do is be clear about it's limitations.
- est31 7y ago> However, if your disk is exposed -- lots of other things, including shell history, swap, etc. may give you away. Good that you point out shell history. You probably mean stuff like secrets being passed to age via CLI params? That's quite dangerous even if you put a space before the command which excludes it from your shell history. Any user on your system has read-access to the CLI arguments of every other process on your system. I've filed an issue upstream about this: https://github.com/FiloSottile/age/issues/37 https://github.com/FiloSottile/age/issues/37 I've mentioned swap in my comment. It's a problem indeed. On Linux you can prevent memory regions from being swapped out via mlock, but only to a certain limit if you are unprivileged (limit on my machine is 64 MB it seems). Windows seems to have a way as well. It's solvable in general and RAM is cheap. It's OSs that have to catch up. Even with the looming swap danger, your data is still more safe in RAM as it doesn't neccessarily get swapped while if it's on your hdd/ssd, it is almost certain to actually land there as well (instead of living in the RAM's cache). > The problem with stuff like "gives users read/write access" -- is that it presumes a narrow use case. What if you're encrypting digital audio? Source code? etc. That's a good point. Due to the point you made above (swap, shell history, etc leaking data to disk), it would be best if specialized tools handled the file, which are vetted to not leak any data onto the disk. You could think of a model where age is a library, the tools manually vetted with that in mind. Or you could think of a model where age is embedded into a runtime and the tools are sandboxed wasm modules without access to anything but RAM. Admittedly this is a huge project and one shouldn't expect age to be such a runtime. A good stopgap would age enforcing best practices by checking whether the destination of the decrypted content is a ramdisk or not. I've filed an issue about this: https://github.com/FiloSottile/age/issues/36 https://github.com/FiloSottile/age/issues/36