Also applied to gpgme.

Since there is no problem with libgpg-error 1.43, I applied it to other libraries: npth, libassuan, libksba, and ntbtls.

I'll fix regressions: failures of pubkey and pkcs1v2.

Friendly ping @werner

Yes, keep the internal SHA-3.

We will have rnd-getentropy.c

Blowfish is not part of OpenPGP and according to its creator not the best cipher. Sorry to say no. You may nevertheless be interested in the recent discussion threads on PQC on the cryptography ML.

Applied and pushed symmetric algo for basic.

Let me clean up rndlinux.c for current use case, at first.

I decided to use 3.3.0 disabling pthread feature.

Any news here? Is this issue going to be fixed or not? It's really annoying.

Thank you for merging the important parts of the patches and implementing similar stuff for DSA. You are right that DSA is supported in the 140-3 specs so it is fine to keep it enabled with the keylength constraints.

Applied parts except part 2.
The part 3 are modified version, so that memory can be released correctly.

Closing. In case the audit will request more, we can re-open this task.

I think we can close this. In January we will have an external audit (BITV) which hopefully will confirm our tests. They auditor will also provide a list of things to improve (if any).

Implicit indicators mean that we need to go through the all algorithms and verify that they work if they have approved key sizes/parameters and do not work when they do not.

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