FiloSottile
Using the same file as input and output produces a corrupt result without notice.
Environment
- OS: Linux (nixos-unstable)
- age version: 1.1.1
What were you trying to do
Trying to encrypt a file in-place with age -p -o file file. I was trying to password-protect my age-secret-key,
which corrupted it irrevocably.
What happened
The resulting file is written while it is read, resulting in a data-race causing the newly written data to be used
in the current encryption. Due to the header overwriting the original data, the original content is lost. rage seems to be able to detect this and abort before doing any damage, and it would be great if age could also detect this.
# echo oops > test
# age -p -o test test
# cat test
age-encryption.org/v1
-> scrypt ukvhgUSL+2LmAzEKVMP4Bw 18
eyjc0VaSQN0oeFBqlTMRV9Tt4HLP25UpCCl1zgk5jT4
--- rqxebQUnlQ+DShsBKtxxfFvVm69wHaNdXX16Tm99eT8
<SMALL-AMOUNT-OF-BINARY>
# cat test | age -d
age-encryption.org/v1
-> scrypt ukvhgUSL+2LmAzEKVMP4Bw 18
eyjc0VaSQN0oeFBqlTMRV9Tt4HLP25UpCCl1zgk5jT4
--- rqxebQUnlQ+DShsBKtxxfFvVm69wHaNdXX16Tm99eT8
<LARGE-AMOUNT-OF-BINARY>
For reference, I implemented this check in https://github.com/str4d/rage/pull/202 (after agreeing to change rage -o to match age's behaviour and overwrite existing files in https://github.com/str4d/rage/pull/168).
I implemented it and pushed a pull request. Feel free to try it. I'm already using it.
I have (likely) the same issue using armored encoding.
Will the PR fixing this be merged?
Thanks for the update.
Given that this regrettable characteristic irremediably corrupts original files, it's really scary that this is still active in the current release (1.1.1) one year after initial report... :man_shrugging:
Thank you for the report. We can't save the user if they use the shell's < or >, but we now detect what we can.
