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

Looks like this spot was missed when T5037: dn.cpp:181: suspicious loop was fixed. In libkleo's copy of the DN parser I applied the fix in 2023. Too many copies!

Make all table column headings accessible (see Update 2025-10-27).

Fixed and backported for VSD 3.4.

The settings should work again. They are described at https://docs.kde.org/trunk_kf6/en/kleopatra/kleopatra/admin.html#admin-certificate-request-wizard-keys , but note that the documentation is severely outdated. Note that those settings are not officially supported by GnuPG (VS-)Desktop (see https://gnupg.com/vsd/kleopatra-settings.html).

Should work now.

This was fixed in Qt 6.10.0 by adding compatibility code that's "hidden" behind a compiler flag, i.e. we just need to enable this compiler flag. See https://codereview.qt-project.org/c/qt/qtbase/+/629255 for details.

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!

I'm pretty sure that this has already been fixed with the changes made for T8083: Kleopatra: Use blue icon for Gpg4win and GPD. build-appimage.sh now always replaces the Breeze icons shipped with the AppImage with the appropriate head icon.

I guess the test fails because one cannot create a key with an expiration date before the current date. And the test tries to create a key which expires on 2038-01-01 which will fail if the test is run on 2038-01-01 or later. The easiest fix would be to disable the test cases if the current date is past 2038-01-01.

Okay, then I set the ticket to Testing.

If the user clicks the "No, others also use this key" button they get the following dialog

I was curious: Similar to the kiosk/immutable feature of kconfig, gpgolconfig allows to flag values as immutable by appending a '!' to the value set in the registry. If autoencryptUntrusted is set to 0! via the registry then the checkbox should be disabled.

@werner: Shall we backport the fix to the gpgme-1.24-branch or do we just add a patch to gpg4win's gpg4win-4-branch and/or vsd-3.3-branch?

I have verified (by locally applying the change to a Gpg4win 4 build) that ifdef'ing-out the above hack for Windows builds fixes the display issue.

The capping of the date seems to be caused by this workaround/hack in gpgme's _gpgme_parse_timestamp

/* Fixme: We would better use a configure test to see whether
   mktime can handle dates beyond 2038. */
if (sizeof (time_t) <= 4 && year >= 2038)
  return (time_t)2145914603; /* 2037-12-31 23:23:23 */

Now an expired signature with certified key is reported like this:

It looks like we get a specific "Invalid public key algorithm" error from gpgme so that we can add helpful information with likely reasons to the error message.

The blue Kleopatra icon is now used for the Windows builds of Gpg4win and GPD and for the corresponding AppImages.

Backported for VSD 3.4

Fixed. Kleopatra now looks for programs given as plain name (i.e. without any path) first in the GnuPG installation path (as reported by gpgme) and then next to the kleopatra executable. If the program is found at neither location it is run as-is.

The AppImage now displays the same version as the Windows builds, i.e. in particular Gpg4win-VERSION for the "default" build.

In T7509#212953, @timegrid wrote:

Is the displayed version 4.0.0.260370 right for the appimage? shouldn't this also display the gpg4win version?

Is this wording / layout okay?

Using an icon for QES certificates isn't that easy because we use an icon for smartcard certificates and any list item can have at most one icon. Moreover, QES certificates are very like stored on a smartcard (isn't that even a requirement?), i.e. an icon clash is basically guaranteed.

Additionally, the de-vs-compliance filters are no longer show in non-compliant installations like Gpg4win.

Done and backported for VSD 3.4

We decided to still use the term "Valid" (with description/tooltip "Certificates that are neither expired nor revoked (except disabled ones)"). This matches the use of the term "invalid" for expired and revoked certificates as in "Certificates that are invalid because they have expired (except disabled ones)".

This overloading of "bold" for "my certificates", "qualified certificates" and "trusted root certificates" seems to exist since two decades. I stopped digging into ancient history at the commit that added the hard-coded default filters.