Fixed in 1.12.1.

Cool. Works for me now.

rG62b8bf2f introduced the regression. The intent of the fix was about comparison of -----END , which has nine characters.
But it also added afx->buffer_pos ==1, that affected.

Using --enarmor and removing the checksum I sometimes get

Fixed in libgpg-error 1.59.

I came from it with stuffing the vector into a QByteArrayView - and then comparing it with the same string being roundtripped thru a copy/paste operation by the user.

I explicitly keep the null byte so that you can simply pass the (pointer to the data of the) vector of bytes to the std::string c'tor. Meh! The c'tor wants const char *, but the vector is const unsigned char * so that one has to reinterpret_cast.

I don't think the trailing zero-byte should survive the conversion to c++ datastructures.

I have documented the function. The documentation is essentially a copy of the documentation of gpgme_op_random_bytes which should make clear that the function essentially behaves like gpgme_op_random_bytes (except that the gpgmepp function creates a buffer instead of taking one).

I guess it would have been better gpgmepp API to add an additional function for getting 30 zbase32 bytes and to omit the mode flag in the generateRandomBytes function instead of mirroring the API of gpgme.

I don't consider this a bug in gpgmepp's code. gpgmepp behaves exactly like gpgme (because it simply calls gpgme_op_random_bytes after creating a buffer of the requested size). With zbase32 you get 30 bytes zbase32 code and, if you requested more bytes, you get uninitialized additional bytes (which happen to be nullbytes, but that's more accidental than intentional). If anything then the problem is that gpgmepp's API is in general un(der)documented.

Yeah. It's a gpgmepp bug.

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.

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

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

Maintainer of the FreeBSD notmuch port/package here. The steps below consistently trigger the problem on FreeBSD 16.0 (unreleased main branch), but there are no problems on FreeBSD 15.0. All my testing was on amd64.

Yeah sure.

In T8101#213455, @werner wrote:

You need to use a current Windows version (and not Windows Server 2016)

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

@thesamesam Thanks a lot.
I managed to replicate the failure somehow (for me, it fails at the importing the key).

I've attached notmuch-bug.log with debug-level guru commented out for gpg-agent:

I can reproduce it using Stuart's script from https://lists.gnupg.org/pipermail/gcrypt-devel/2026-February/006031.html.

Please tell us the information of your environment.
What the versions of gpg and gpg-agent?

Here is an attempt of mine this week:

diff --git a/g10/call-agent.c b/g10/call-agent.c
index 5e13a3e52..8949fad17 100644
--- a/g10/call-agent.c
+++ b/g10/call-agent.c
@@ -3290,13 +3290,14 @@ confirm_status_cb (void *opaque, const char *line)
    message.  If FORCE is true the agent is advised not to ask for
    confirmation. */
 gpg_error_t
-agent_delete_key (ctrl_t ctrl, const char *hexkeygrip, const char *desc,
+agent_delete_key (ctrl_t ctrl, const char *keygrip, const char *desc,
                   int force)
 {
   gpg_error_t err;
   char line[ASSUAN_LINELENGTH];
   struct default_inq_parm_s dfltparm;
   struct confirm_parm_s confirm_parm;
+  const char *keygrip2 = NULL;

We have seen the same thing on amd64 (x86_64) linux: https://bugs.gentoo.org/969501

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

The fix causes a regression. Reported: https://lists.gnupg.org/pipermail/gnupg-devel/2026-February/036218.html

This is not 2.5-only.

Hi, the test is green with rG86baca6e62b3 for both 2038-01-01 and 2105-01-01. Thanks!

For the time being I "upgraded 5.0.1 to 4.4.1 (in the new directory), and then Kleopatra started again.
When upgrading that installation again to 5.0.1, Kleopatra does not start (same error message as before).

Also: When I click "Abort" ("Abbrechen"), the dialog disappeared, but the main windows does not show any progress: Specifically it does not abort.
I had to press "Abort" ("Abbrechen") in the main window; then the upgrade aborted.
When retrying (and confirming that I don't want to install as Administrator (actually I cannot), the proposed target directory still is "C:\Program Files\Gpg4win".
When locating the previous installation directory (it seems it was a subdirectory of %USERPROFIL%\Downloads) the upgrade succeeded, but Kleopatra fails to start.
It want a bin\Qt6Core.dll, bit in the bin directory there is only a Qt5Corew.dll dated " 14. ‎Juli ‎2023, ‏‎13:23:40".
When retrying the installation/upgrade it announced to upgrade 5.0.1, but then did seemingly nothing (I guess as the version was estimated to "be current").
It seems some "reinstall/repair" option is missing.

No, OpenBSD's implementation of POSIX semaphore is different to NetBSD.
(It doesn't support PSHARED=1.)

Possibly, it is related to the NetBSD failure of T8065.
If importing the secret key fails (which invokes gpg-agent), decryption cannot be succeeded.
I will check OpenBSD implementation of POSIX semaphore, if it's similar to NetBSD one.

We forgot to update the tooltip when the default keyserver was removed in gpg 2.5.3. This has already been fixed in the meantime. Sorry for the inconvenience!