add gpgcrypt plugin

[vkareh]

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 gpg and a working gpg-agent.

For symmetric encryption:

1. echo "hello world" | gpg --symmetric -o /tmp/test1.gpg
2. pluma /tmp/test1.gpg
3. edit file, save
4. gpg --decrypt /tmp/test1.gpg
5. verify decryption is symmetrical (i.e. password prompt)
6. verify decrypted text

For assymmetric encryption:

1. echo "hello world" | gpg --encrypt --default-recipient-self -o /tmp/test2.gpg
2. pluma /tmp/test2.gpg
3. edit file, save
4. gpg --decrypt /tmp/test2.gpg
5. verify decryption is asymmetrical (i.e. smart card or yubikey required)
6. verify decrypted text

"Save As" to GPG:

1. Open plaintext file or create new one
2. Save As /tmp/test3.gpg
3. (there should be a password prompt)
4. gpg --decrypt /tmp/test3.gpg
5. verify decrypted text

"Save As" away from GPG:

1. pluma /tmp/test3.gpg
2. Save As /tmp/test4.txt
3. verify file saved plaintext with no encryption

[mbkma]

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.

[vkareh]

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.

Good point. I've removed --batch from the symmetrical flow (and I get a nice password prompt now, instead of using the one cached in my keyring)

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've made this a bit better by restoring the encrypted backup on save in the same operation, so existing files will never persist to disk unencrypted. For new files there's still a brief window where the thread opens up to encrypt and before it finishes that the file could be plaintext in disk briefly. I don't think we can avoid that (or not sure how at least).