FWIW: Okay, gmime is still a wrapper around gpgme. After decryption it has the ability to get the used session key from the gpgme result structure. Thus, I have been on the wrong trail. The actual problem is not gpgme but more GnuPG's use of Libgcrypt or an actual regression in Libgcrypt. Well, Friday 13th.

This has been specified in 1997 by PGP 5 for a good reason. We talked often enough about this and it does not help to repeat your ideas over and over again. RFC9580 specifies a different protocol than OpenPGP as specified by RFC2440 and RFC4880 but alas grabbed the name OpenPGP for this.

I can't speak for gpgmpp but for gpgme. And the gpgme manual says:

Has now been backported to be released with 2.2.53

Yeah sure.

keys.openpgp.org has two problems: a) it is a centralized service due to the requirement to confirm mail addresses. b) For non-confirmed keys it returns broken OpenPGP keys (ie. without a user id and thus without important information). For these reasons and the general problems with the keyserver-(networks) there is no more default.

Shall we change log_* functions also emit message to console, when file/socket is specified?

Any hints where to find the actual crypto code which uses libgcrypt?

I'm surprised that nobody did detect these problems during the long beta phase...

Please do not use the portable installation - it is dangerous to use it. We will eventually remove this option.

I also updated the software page. Thanks for the hint.

Done. See T7449

Noteworthy changes in version 0.11.1 (2026-02-12)

Won't fix for vsd3x

According to the ML @gniibe tried to replicate the problem without success.