I saw that it used a streaming AEAD, but that's actually what inspired my question.
Since (from the github page) it reads stdin, it can't two-pass the file.
So it appears that if you hand it a file with midstream corruption it's going to feed a truncated input down your pipeline.
That has consequences. They may well be less serious consequences than buffering a potentially unlimited amount of data in memory :), but it's useful to make the behavior very clear because it wouldn't require too advanced an idiot to make something that was exploitable on this basis.
The AGL post the spec links to directly talks more generally about the high-level strategy: you're buffering chunks of files. You're only ever releasing authenticated plaintext. If you're piping to something processing plaintext on-line, that thing might need to wait for the end-of-file signal before processing or else potentially operate on a truncated file (by some integral number of chunks). `age` is still just a Unix program.
That behavior should be clearly documented, so that users can be advised that their pipelines need to safely handle that case.
> that thing might need to wait for the end-of-file signal before processing or else potentially operate on a truncated file
Exactly. The docs should say this clearly, or someone will manage to create an interesting vulnerability with it eventually. :)
Could go with a message the points out that encryption doesn't authenticate the source-- which is a not uncommon misuse that shows up with PGP, where people assume that the source is authentic if the input was encrypted, even where no signature is used. (the fact that corrupted input gives an "authentication failed" message might be particularly misleading)
