Recipients lost after opening file. about vim-gnupg

[jamessan]

Can you show the output of the following commands on a file where you're experiencing this issue?

• gpg --verbose --decrypt --list-only --dry-run foo.gpg
• gpg --verbose --decrypt --list-only --dry-run --status-fd 2 foo.gpg >/dev/null
• gpg --verbose --decrypt --status-fd 2 foo.gpg > /dev/null

[jamessan]

By supporting vim modelines in the encrypted content, it would be easy to specifiy a list of recipients in the decrypted content. Not sure whether this is feasible though.

Even if it were, it's not something I would do. I find modelines problematic from a security perspective in general and would not want to implement my own ad-hoc modeline-like support for this plugin.

[oddlama]

Here's the output you asked for:

$ gpg --verbose --decrypt --list-only --dry-run foo.gpg
gpg: Note: RFC4880bis features are enabled.
gpg: public key is 0x0000000000000000

$ gpg --verbose --decrypt --list-only --dry-run --status-fd 2 foo.gpg >/dev/null
gpg: Note: RFC4880bis features are enabled.
gpg: public key is 0x0000000000000000
[GNUPG:] ENC_TO 0000000000000000 18 0
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] END_DECRYPTION

$ gpg --verbose --decrypt --status-fd 2 foo.gpg > /dev/null
gpg: Note: RFC4880bis features are enabled.
gpg: public key is 0x0000000000000000
[GNUPG:] ENC_TO 0000000000000000 18 0
gpg: encrypted with ECDH key, ID 0x0000000000000000
[GNUPG:] KEY_CONSIDERED 680AXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0
gpg: anonymous recipient; trying secret key 0x4255XXXXXXXXXXXX ...
gpg: pinentry launched (350008 qt:curses 1.2.0-unknown /dev/pts/0 xterm-256color - 20620/1000/5 1000/1000 0)
[GNUPG:] PINENTRY_LAUNCHED 350008 qt:curses 1.2.0-unknown /dev/pts/0 xterm-256color - 20620/1000/5 1000/1000 0
gpg: pinentry launched (350079 qt:curses 1.2.0-unknown /dev/pts/0 xterm-256color - 20620/1000/5 1000/1000 0)
[GNUPG:] PINENTRY_LAUNCHED 350079 qt:curses 1.2.0-unknown /dev/pts/0 xterm-256color - 20620/1000/5 1000/1000 0
gpg: pinentry launched (350099 qt:curses 1.2.0-unknown /dev/pts/0 xterm-256color - 20620/1000/5 1000/1000 0)
[GNUPG:] PINENTRY_LAUNCHED 350099 qt:curses 1.2.0-unknown /dev/pts/0 xterm-256color - 20620/1000/5 1000/1000 0
[GNUPG:] KEY_CONSIDERED 680AXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0
gpg: using pgp trust model
[GNUPG:] DECRYPTION_KEY EF5C0XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 680AXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX u
gpg: okay, we are the anonymous recipient.
[GNUPG:] BEGIN_DECRYPTION
gpg: AES256.CFB encrypted data
[GNUPG:] DECRYPTION_INFO 2 9 0
gpg: original file name=''
[GNUPG:] PLAINTEXT 62 1649002851
[GNUPG:] DECRYPTION_OKAY
[GNUPG:] GOODMDC
[GNUPG:] END_DECRYPTION

I've redacted my actual key id's by replacing some hex values with XXXX as you will see above. It might be noteworthy that only the last command requested access to my security key. Tell me if you need anything else.

Even if it were, it's not something I would do. I find modelines problematic from a security perspective in general and would not want to implement my own ad-hoc modeline-like support for this plugin.

I feel the same way security wise. Could've been a dirty workaround to the problem, if not fixable by other means.

[jamessan]

Ok, so the last option gives us some information to use. This basically boils down to a duplicate of #121. The plugin needs to change to use --status-fd.

However, even with those changes, recipients are still going to be "lost" since they're not recorded in the file. The only recipient that will be retained is you, and you can achieve the same by adding encrypt-to <your key> in ~/.gnupg/gpg.conf.

[oddlama]

Unfortunately I have several security keys and some files are encrypted with key A and others with key B. So an entry in ~/.gnupg/gpg.conf will not really work.

What would prevent this plugin from parsing which secret key worked for decryption and use that instead of an empty list of recepients? This would absolutely solve the problem for me.

[jamessan]

What would prevent this plugin from parsing which secret key worked for decryption and use that instead of an empty list of recepients?

Nothing. :) That's something I agree should be fixed. However, that will only preserve yourself as a recipient, not any of the other recipients. That's the only caveat I was pointing out.

[oddlama]

Ah I'm sorry. I interpreted your previous message as "[all] recipients would be lost", which we agree isn't the case. Thanks for clarifying. :)