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

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.

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!

Fixed for KF6 versions.

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.

Won't fix for vsd3x

Meanwhile all executables are signed.

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

Investigating GNU ld, I learned that there is no easy way (~= no way) to suppress the warnings (other than 2>/dev/null). It was implemented by the special section named gnu.warning.SYM where SYM is a symbol. I think that this is not-so-good for glibc to notify its users about possible static link problem, by gnu.warning.SYM.

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.

Unfortunately, this was run on x86_64 and also other 64 bit archs.

Is that on a 32 bit machine or 64? The latter would be a problem for 32 bit with 32 bit time-t I'd say: we won't fix it.

At least for an expired data signature I would suggest to have an info button to further expliah this. Maybe to a FAQ or KB article. The case is too rare that we should not discuss endlessly the pros and cons of expiring signatures. I hope that Kleo does not provide an option to crerate such a signature.

Sorry for the ambiguity. The request was only about mentioning (bpX) for the first two choices, not to add more combinations.

Your fix is okay.

AFAICS all conditions are protected by isascii(3) which

Physical experiment feature support should better not be widely used.

Although it is technicall possible to use all combinations, we should limit in the menu them to those as listed above. Too many algorithms pose an interop problem. Thus we provide brainpool because it is required in Germany and the two IETF curves for the general internet (for those who are playing mitigation against against physical experiments).

After serveral clever attempt, I've settled to this simple workaround that seems working despite being quite inefficient: if you don't find any key with gpgme_op_keylist_next and gpgme_err_code(err) == GPG_ERR_EOF on a ctx with keylist mode set to GPGME_KEYLIST_MODE_LOCATE, try again (even on the same context), after

Looking to workaround this issue, I've noticed something that might be useful during debug.

Note: In vsd it must be restricted to the bp algorithms then