Conversation
mbkma
left a comment
There was a problem hiding this comment.
I think this still needs another pass before it is ready.
For the symmetric-encryption path, _encrypt_content() builds the gpg command with --batch --yes and then adds --symmetric. That works only if a passphrase is already available non-interactively, but for a new .gpg file gpg normally needs to prompt for the passphrase. With --batch in place, that path is likely to fail instead of letting the user complete the save.
There is also still a plaintext-on-disk window during save. The comment in the save handler already calls that out, but it means a crash or power loss between the plaintext write and the re-encryption step can leave the file unencrypted on disk.
I'd fix the symmetric save path first, and then decide whether the current save flow is acceptable from a security point of view or needs a stricter approach.
Add a plugin that opens and saves GPG-encrypted files (.gpg, .pgp). On open, the file is decrypted via the gpg CLI; on save, it is re-encrypted using the original method (symmetric or asymmetric with the same recipients). New files saved with a GPG extension default to symmetric encryption.
Add a plugin that opens and saves GPG-encrypted files (.gpg, .pgp). On open, the file is decrypted via the gpg CLI; on save, it is re-encrypted using the original method (symmetric or asymmetric with the same recipients). New files saved with a GPG extension default to symmetric encryption.
To test, enable the plugin, and make sure you have
gpgand a workinggpg-agent.For symmetric encryption:
echo "hello world" | gpg --symmetric -o /tmp/test1.gpgpluma /tmp/test1.gpggpg --decrypt /tmp/test1.gpgFor assymmetric encryption:
echo "hello world" | gpg --encrypt --default-recipient-self -o /tmp/test2.gpgpluma /tmp/test2.gpggpg --decrypt /tmp/test2.gpg"Save As" to GPG:
/tmp/test3.gpggpg --decrypt /tmp/test3.gpg"Save As" away from GPG:
pluma /tmp/test3.gpg/tmp/test4.txt