Not decrypting after upgrade to GnuPG 2.3.4

[KenKundert]

I just upgraded to Fedora35, which presumably upgrades both Vim and GnuPG, but I believe the issue is with GnuPG. Now when I try to open an encrypted file with vim, vim -v, or gvim, the content of the encrypted file is not decrypted. If I turn on debugging, I see:

GnuPG: >>>>>>>> Entering gnupg#decrypt(1)
GnuPG: command: gpg2 --use-agent --verbose --decrypt --list-only --dry-run --no-use-agent --logger-fd 1 '/tmp/test.gpg' 2>/dev/null
GnuPG: rc: 0
GnuPG: output:
GnuPG: this file is not encrypted

Upgrading vim-gnupg to the most recent version in GitHub does not help.

If I run that same gpg command from a shell I see:

$ gpg2 --use-agent --verbose --decrypt --list-only --dry-run --no-use-agent --logger-fd 1 '/tmp/test.gpg'
gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect

Notice that the expected output is missing. There is just the warning. Eliminating the --no-use-agent option gets rid of the warning, but the expected output is still missing.

I am at a loss at this point. I played around with the command line options some, but cannot figure out how to get gpg2 to generate the expected output.

I would appreciate any insight or help you can offer.

Oh, and thanks for writing and supporting this plugin. I find it use it all the time and love it.

[jamessan]

Thanks for the report. I'll have to test it out and see what's going on.

[jamessan]

Did some bisecting and the problem started with gnupg commit ce2f71760155b71a71418fe145a557c99bd52290.

Before that commit, the output looks like:

gpg: public key is 0xA1F9838CBD46A1A8
gpg: using subkey 0xA1F9838CBD46A1A8 instead of primary key 0xDFE691AE331BA3DB
gpg: encrypted with 4096-bit RSA key, ID 0xA1F9838CBD46A1A8, created 2011-12-05
      "James McCoy (Debian) <[email protected]>"

but after it's just:

gpg: public key is 0xA1F9838CBD46A1A8

[jamessan]

Actually, your initial report said you weren't getting any output other than the warning? What if you run gpg2 --verbose --decrypt --list-only /tmp/test.gpg, @KenKundert?

[KenKundert]

Yes, I looked at the source for vim-gnupg and determined the exact gpg command it ran, and then I ran it myself, both on my recently updated Fedora 35 machine, and a Fedora 34 machine. If I remember correctly, the command I ran was very similar to the one you suggested. I seem to recall adding --dry-run, but other than that I think it was the same. On Fedora 35 there was nothing; on Fedora 34 it produced the expected output. I then tried adding a second --verbose. Then gpg did produce output, but not the output that was needed.

I use vim-gnupg on a daily basis, so I needed a work-around. I found that using "gpg --list-packets" got me what I need to support asymmetric encryption, and then I hacked vim-gnupg to make it work, but its ugly.

This feel like a mistake in gpg. It seems like they did not provide a standard way to determine the important parameters for an encrypted file that are needed when re-encrypting, and so you used what you could find. Then they made an innocent change that broke your code. I figured it would be best if you worked with the gpg folks directly to get them to officially support an interface that provides the interface you need.

[KenKundert]

One more thing. The behavior I am seeing is a little different from what you are seeing. When I run gpg2 --verbose --decrypt --list-only /tmp/test.gpg I get no output at all in my terminal. That is probably because I have a log file set in my gpg.conf file. I do see the public key line in my logfile.

If I remove the log-file setting from my gpg.conf file I get the following:

gpg: Note: RFC4880bis features are enabled.
gpg: public key is 0x96AC5259C5B06098

[jamessan]

That is probably because I have a log file set in my gpg.conf file. I do see the public key line in my logfile.

This is the relevant information. :) All I need is the public key is ... line. With that, the plugin should work fine as far as detecting whether the file is encrypted.

[jamessan]

I've opened https://dev.gnupg.org/T5849.

[KenKundert]

A simple work around and an eventual solution. Excellent. Thanks!

[szaffarano]

Hi @jamessan and @KenKundert
Thanks for the tip; after removing the logging option in my gpg.conf file fixed the issue :)