IIRC, support for the keybox fomat was added on Debian's request with 2.1.7 in 2015 to gpgv. In fact gpgv was written on Debian's request (1.0.4 from fall 2000).

I guess you need to report this to Debian as their new sqv tools seems to be broken.

Cool. Works for me now.

Using --enarmor and removing the checksum I sometimes get

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...