Notice: the very same vulnerability has been discussed in this question, but the different setting of the problem (in my case I don't need to store the passphrase) allows for a different solution (i.e. using file descriptors instead of saving the passphrase in a file, see ilkkachu's answer).
Suppose I have a symmetrically encrypted file my_file
(with gpg 1.x), in which I store some confidential data, and I want to edit it using the following script:
read -e -s -p "Enter passphrase: " my_passphrase
gpg --passphrase $my_passphrase --decrypt $my_file | stream_editing_command | gpg --yes --output $my_file --passphrase $my_passphrase --symmetric
unset my_passphrase
Where stream_editing_command
substitutes/appends something to the stream.
My question: is this safe? Will the variable $my_passphrase
and/or the decrypted output be visible/accessible in some way? If it isn't safe, how should I modify the script?
gpg
. It will therefore be visible in the output ofps
. It is not possible to call a program with a password on the command line securely. This is whygpg
and other programs that takes passwords often read them from a file. A file can be made read protected for anyone but the file's owner (and root).gpg
throughcron
, which pretty much forces using some sort of persistent storage for the passphrase (i.e. a file).