The footgun you described can still happen if there's a verification error somewhere in the middle. You could still conceivably craft exploits using only truncation of the plaintext, depending on the situation.
No one should "decrypt < file | sh" (or anything | sh without verifying), but they will. Doesn't matter if we have POSIX or non-POSIX shell flags that can fix it, the defaults are bad.
There's nothing tools like age can do about that, though.
Edit: I was thinking more along the lines of
if decrypt < file | postprocess > tempfile
then
sh tempfile
fi
where postprocess exits zero. This is where the default shell behavior fails. The "decrypt < file | sh" antipattern is something not even the shell can do anything about.
> No one should "decrypt < file | sh" (or anything | sh without verifying)
I was thinking of self-prepared scripts, tooling or owner controller distribution. Decrypt+good signature is precisely what I want.
Anyway, as nmadden pointed out, age does not provide source authentication duh. AFAIU that means, all the streaming semantics and blockwise AEAD are practically useless, unless you are using the password encryption, which is helpfully blocked from automation.
The footgun you described can still happen if there's a verification error somewhere in the middle. You could still conceivably craft exploits using only truncation of the plaintext, depending on the situation.
No one should "decrypt < file | sh" (or anything | sh without verifying), but they will. Doesn't matter if we have POSIX or non-POSIX shell flags that can fix it, the defaults are bad.
There's nothing tools like age can do about that, though.
Edit: I was thinking more along the lines of
where postprocess exits zero. This is where the default shell behavior fails. The "decrypt < file | sh" antipattern is something not even the shell can do anything about.