Packet 20 is the new AEAD packet which GnuPG 2.3 can generate and does generate if all recipients have new keys generated with such a versions. However, the version of gpg you use now does not support AEAD and thus fails.

Since decryption is broken, I'm raising the priority level of this ticket.
It would be wonderful if someone can take a more detailed look into this problem. :)

Please refer to the open Mutt Bug issue 401 below regarding the troubleshooting we've performed which seems to suggest there *might* be something a skew on the gpg binaries.

Sorry, without detailed output of gpg we can't help you here. This is definitely not a GnuPG bug because too many people are using mutt and gnupg. You should also "set crypt_use_gpgme" -it works far better.

Feel free to ask me by PM if you run into problems (wk at gnupg.org). Two of my colleagues are Vim users and thus have an interest in a well working plugin :-). Thanks.

Enable the setting Create OpenPGP encrypted files with ".pgp" file extensions instead of ".gpg in Kleopatra's Settings.

Rename the file and you are done.

Sure there are logs, see the options log-file and debug in the man pages.
To sign using specific subkey or the main key, use the fingerprint of the key and append an exclamation mark.
For example

I'm pretty sure that the first 3 messages are always decrypted with the first key because the passphrase of the first key is still cached. I don't think you can tell gpg to only use a specific key for decryption. The only way to make sure that gpg does not try to use the first key for decryption is to remove the private key of the first key. Alternatively, clear the cache after using the first key, but gpg might still ask the user for the passphrase of the first key.

That looks like a support question. Please ask on a mailing list for help. Sorry, we can't do individual support here.

Thank you for locating the bug!

Hi gniibe!

Fix for this issue landed RNP master, and will be included to the RNP v0.16.0 release.
Within fix:

• new keys will be generated with correctly tweaked bits
• using secret key with non-tweaked bits would issue a warning
• CLI command --edit-key [--check-cv25519-bits | --fix-cv25519-bits] added, allowing to fix older key

Please ask on a mailing list etc. This is a bug tracker and pnly very few people are reading your report.

Sorry, I just discovered that I had to click on "Save All" in order for the file to be actually stored in the disk and then it works.

Here it goes...

Sure.

And it shows

Thank you so much for your explanation.
I just want to try with older version. Because when I try to run

Thank you for your investigation.

Hi gniibe!

After testing about a dozen different term types and doing some library tracing, it appears to be that any terminfo type for which has_colors() is false (so the start_color code is never called) works correctly.

Hi gniibe!

Another link: http://hea-www.harvard.edu/~fine/opinions/xterm-problems.html

All of my testing has been done while connecting via ssh to my OpenIndiana workstation. I'm using PuTTY 0.76 as my terminal/SSH client.

It appears to you identified the problem really quickly again. If I select the entire screen and paste it, the dialog text is there:

@mooney Just in case when it's color related problem, could you try to cut&paste the text of the screen when pinentry should display a dialog box?

I found some links:
XTerm FAQ:
https://invisible-island.net/xterm/xterm.faq.html
Why not just use TERM set to "xterm"?
https://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic
What $TERM should I use?
https://tools.ietf.org/doc/xterm/xterm.faq.html#xterm_terminfo

Ah well, Kleopatra has a GUI to set the keyserver - that is probably easier to use.

Here is James' writeup on the use https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html . For more details please consult the mailing lists and the commit messages.

I think that scenario with TPM emulation would be more generic.
What needs to be done to have TPM emulation? Can you point on some doc about that?

Ich you do not have a working TPM or emulation but the tpm libraries installed run configure with the option

--disable-tpm2d

In T5411#149872, @aheinecke wrote:

Our windows explorer plugin keeps libgpg-error loaded when you install an upgrade. That is why our installer asks for a reboot at the end of the install. You have ignored the reboot and you then get the error.

We have another ticket T5012 for this issue.

Our windows explorer plugin keeps libgpg-error loaded when you install an upgrade. That is why our installer asks for a reboot at the end of the install. You have ignored the reboot and you then get the error.

I had the same issue opening GPA or Kleopatra going from 3.1.14 to 3.1.16 on Windows 10. I don't have Outlook installed.

Thanks for clarification, indeed attempt to decrypt data returns an error afterwards.

Well, while importing you get the warning:

Yes, for migration from GnuPG 2.0 reasons, a batch import delays the key checking (i.e. converting from OpenPGP to GnuPG internal format) to the first use. Thus you don't see an error immediately. But if you encrypt something , you won't be able to decrypt it again:

Thanks, Werner.
During further work on this got another issue:

Thanks. I meanwhile pushed a fix to 2.3 so that a warning is shown if the low bits are set.

Thanks for the replies, this makes things clear. We'll update RNP to correctly set/unset those bits while saving a generated secret key and a way to fix up previously generated keys.

Right, as long as there is only one format in widespread use (based on a long existing 4880bis draft) only this format should go over the wire.
Thus, it is a matter how the key is exported. In cryptography you should never have several options - one clearly defined format is what you want. We have had enough trouble with PGP5 peculiarities but in that case their implementation had more users and thus GnuPG had to work around it. Not good, but there was no standard at all at this time.

@onickolay No sorry needed. It was me, who cannot answer promptly.

@gniibe sorry for pinging, but this issue gets attention as TB users (with RNP OpenPGP backend) cannot import to GnuPG EdDSA secret key which was generated by RNP since it doesn't tweak bits when storing or exporting a secret key.
Should we update RNP to tweak those bits during storage to be more compatible (given that those bits doesn't make any difference)?

Nah, I think I laid out all my arguments by now. I don't have more to add, so I'll just let it be.

Not at all. But 2.1 was such a large change that users really should have read the announcement and think about their use case. We have exensivly communicated the changes and can expect that users test their new installation. IF you have further comments, please use the mailing list.

I'm still sad that you don't acknowledge the problem I am describing. It seems that you are writing your software for the kind of user who reads all your documentation first. That kind of user does not exist.

The option has been removed form the repo more than 11 years ago and the gnupg with this changes (2.1.0) was released 7 years ago including an extensive writeup on all the major changes including notices that the secret keys will be converted and moved.

I propose the following patch to inform the user about the obsolete --secret-keyring option. The same is done for many other obsolete options.

This is very saddening and alarming from a respected member of the community whose opinion matters.

Please try 3.1.16 and make sure that you don't have other variants of gpg4win installed or Outlook plugins also using parts of gpg4win or its libraries.

You should have read the release notes of 2.1 (first point). We can't keep a bug open because you had a wrong understanding of GnuPG properties. Sorry.

Well, the keys are not generated but public keys are imported. @gniibe's key has meanwhile expired but we keep it because it will allow users to verify some older source packages. An expired signature key is not an error but merely means that one should evaluate the meaning of the signature with more diligence.

Sorry, I don't understand what you are trying to say, so let me give you some more detail.

Everything in ~/.gnupg is and has always been private to gnupg unless explicitly stated otherwise.

Check that the file exists and that you have permissions to read the file. You may use an editor to try this out.

Do I correctly understand that issue will be resolved on GnuPG side by tweaking key bits before private-key import/and/or/operations?

We should not support a different OID or representation of 22519 which will only lead to incompatibilities and trouble existing users. 25519 is in too widespread use than to allow for any changes.

Check out https://gnupg.org

But where i can find miling list ? I need get back my pgp key, because it's
now bock.

No, sorry. For help please use one of the mailing lists.

Take care: It is not clear whether you may use a [C} subkey for certification. GnuPG currently accepts this but the RFC can also be read as primary keys needs to to do the certification.

For signing (aka certifying) another key you need a (sub)key with the "certify" capability. Your signing subkey can only be used for signing data but not for certifying keys. This isn't specific to gpgme. See https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21.

Yes, you need the secret part of the primary key. gpgme has this info but it is easy to miss. Even our gpgme/tests/run-keylist.c debug tool did not show it directly. I modified it to make this more clear, see the latest gpgme commit. Here is an example for my key:

$ ./run-keylist --verbose --with-secret  63113AE866587D0A
keyid   : 63113AE866587D0A
caps    : esc
flags   : secret
upd     : 0 (0)
fpr    0: AEA84EDCF01AD86C4701C85C63113AE866587D0A
grip   0: CE5C1F1B8C96F1A078A2D1932EEE738A854ED976
curve  0: ed25519
caps   0: sc
flags  0:
fpr    1: E05BA20ED4F17768613B03C53CD7B3A055039224
grip   1: 7A1E3130C9CBDBF203A0AD8E186D9C511D5019FF
curve  1: cv25519
caps   1: e
flags  1: secret
fpr    2: 8777461F2A074EBC480D359419CC1C9E085B107A
grip   2: FF35C6E765F440145095750DC97D43D496C5ABEA
curve  2: ed25519
caps   2: s
flags  2: secret

Then let's get it in there. It's pretty easy to traverse a directory.

reading your report again: You clicked on a folder and expected that all encrypted files in this folder will be decrypted? That is unfortunately not supported.

I have the same message when i try to decrypt files larger than 1.5GB in size; i atached the report "gpgconf --show-version"

I am also a MacOS Big Sur user who recently upgraded to 2.3.1 and had problems after upgrading. In my use case, I use the yubikey as the authentication for pass password manager which uses gpg under the hood.

I'm referring to this: https://www.gnupg.org/howtos/card-howto/en/ch02s03.html

@colemickens We don't maintain any ccid udev rules in GnuPG. What do you refer?

@gniibe can you provide any commentary on why the gnupg ccid udev rule is so much smaller than the one debian maintains? Is the debian one considered authoritative these days?

Thanks @gniibe, that's very helpful advice and pointers. Very appreciated, cheers.

Perhaps, if a distro haven't offered setting of USB, it would be better to configure GnuPG build with --disable-ccid-driver and only support scdaemon with PC/SC. GPG for Windows does so.

1. It's a breaking change for system with both of PC/SC and CCID. T4673 due to T3300
   • If you configure with no libusb, users don't need 'disable-ccid' option.
2. I don't know how "wide".
3. In Debian, it is maintained here: https://salsa.debian.org/debian/gnupg2/-/blob/debian/main/debian/scdaemon.udev
4. Yes.

Hi, as a contributor to NixOS I'd also like some guidance. I'm testing the 2.3 upgrade ahead of 2.4, and it "breaks" Yubikey UX that I know many of us use. This might be because we appear to not yet install gnupg's CCID udev rules installed. A few questions:

Thank you for the suggestion of disable-ccid that seems to have solved the problem.