Yes, no, maybe. :-) Thanks for asking!

Firstly, applied uncontroversial part in rC976673425784: doc: Reference the new FIPS 140-3

I use unsigned long instead of nfds_t, so that a user doesn't need to include <poll.h> when he doesn't use poll/ppoll API.

Don't apply tests/gpg/t-support.h, it's only for testing this patch.
When test, before running 'make check' please do:

Update to include the change of tests.
Also include a change for tests/gpg/t-support.h to run tests under artificial environment.

I have been using pgpdump for a long time, but it is out of date with regards to ECC. I have looked at its source code but would rather spend my time on my own code.

Please no new levels. And also consider the problems with global config files, conditionals and values taking from the registry. We can't simply do everything in the GUI - it would get too complex and we end up supporting the supportive config dialogs. Maybe a syntax checking editor would eventually be better.

OpenPGP folks now the algo number by heart ;-)

Fixed and tested on Linux. Thanks.

How would you handle a combination of X509 Certificates and PGP Certificates in that case? Wouldn't that require two files?

I suppose you have rebooted the PC after installing GnuPG 2.3.32. Just to make sure. And double check that there is only one dirmngr.exe with version 2.2.32 installed on your system.

I was planning to export the certificates in the usual textual formats (.asc, .pem) with the information about the groups added as armor headers for OpenPGP and explanatory text for CMS. This would allow the certificates to be imported with any software supporting OpenPGP or X.509 certificates. When importing certificates Kleopatra simply looks for the additional group information and adds/updates the groups (probably after asking the user).

Has been merged into master.

I did a complete reinstall after cleaning out the complete system incl. registry.
No change in behavior of Gpg4win.

Regarding the level "internal" I just remembered that gpgconf doesn't list "internal" options. Given that didn't find any internal options that could probably be changed. Or we add yet another level. Or, all invisible options, that shall be offered to users are promoted (or demoted?) from "invisible" to "expert" level.

In T5677#151584, @ikloecker wrote:

Okay, but then we need a new level for those options that really must not be shown in a UI, but that still need to be accessible via gpgconf. In fact, there is the level "internal" which does not yet seem to be used for any options, but that seems suitable at least for the deprecated gpg/keyserver option.

Okay, but then we need a new level for those options that really must not be shown in a UI, but that still need to be accessible via gpgconf. In fact, there is the level "internal" which does not yet seem to be used for any options, but that seems suitable at least for the deprecated gpg/keyserver option.

While we should have an explicit Import setting I would also like to have a file extension like "kgrp" for key group, cgrp for certificate group is already used by another software.
So that we can register this with a file handler in windows so that such files can get an icon and a double click handler.

I had explicitly added these options because for me the whole "GnuPG System" is an expert level configuration. I would rather move the very important options like the agent timeout settings out of this and then maybe show an info when the user first selects those settings that changing options here could lead to errors in operation.

:-) I thought about such a setting, but at first I want to exclude invisible options from Kleopatra's UI.

In D538#5324, @werner wrote:

Having it invisible is okay for me. But we should not support the keyserver option in gpg.conf via Kleopatra anymore. This option needs to be faded out.

Sorry, I obviously forgot to add this vendor.

Having it invisible is okay for me. But we should not support the keyserver option in gpg.conf via Kleopatra anymore. This option needs to be faded out. Actually there are more problems in 2.2 here: In particular the global options are not manageable by a gpgconf. Thus there is no guarantee that the keyserver option actually shows the correct value if global options are used.

FWIW, GPA has a setting where you can select at which level options are shown (but not invisible). IIRC we had the same in Kleopatra but it has been removed.

For libgcrypt, it was fixed in: T5637: Use poll for libgcrypt (support more than 1024 fds)

THX for the quick reply Ingo...

Pushed to branch ikloecker/t5462 for easier integration as rG0a7d772a5c43: gpgconf: Allow changing gpg's deprecated keyserver option.

If I read it right, the version 3.1.0 adds the pthread requirement. Using 3.0.2 should be fine for us.

Install GnuPG 2.2.32 on top of Gpg4win 3.1.16 to fix the problem.

Configuration dialog with reader-port drop down:

The most of the stuff about boot blocking was discussed in the bug https://bugzilla.redhat.com/show_bug.cgi?id=1569393 (private). There were some bugs in our patches, but also some issue in the kernel that locked the boot process (in FIPS mode).

Given it's just in the examples folder it seems strange to remove it, given it doesn't hurt those who don't want to use it, but it's obviously useful to those who want to. But even then, until it's there, why not fix these 2 lines? It's just a config item that will work everywhere

Tehre has never been an option "shared-access" in GnuPG. At least not in upstream. In general we suggest the use of the interal ccid driver, but if you want PC/SC you need to use disable-ccid-driver. This is because 2.3 does not feature an automatic fallback to PC/SC anymore. Using pcsc-shared with OpenPGP cards can lead to surprising effects. You may want to try Scute as PCKSC#11 access module.

Actually we do not really support the systemd thing and it is likeley that the support in GnuPG will eventually be removed again. You may want to contact the Debian maintainer, who took responsibility for all systemd things.

Check for FIPS has been added. (1) and (2) were solved.