We meanwhile have a lot of test cases in our test suite and we see no issue. Closing this bug; feel free to re-open if it is not fixed for your case in 2.4.4.

I did a couple of test on the command line which should be sufficient.

We need to fix 2.2.42 too. This because we backported the responsible patch.

Having a second build system for GPGME is not a good idea. This gives us a headache for maintaining. If you really need this for private things, put this into a contrib directory and make clear that this is a non supported way to build things. And for the Qt bindings I am anyway in favor of removing them from GPGME proper.

It is already implemented and will soon show up in 2.4.4 -)

Sorry, we won't do that. Please search on the Net for reasons why this is not a good idea. In any case you better move to Ed25519 or - if you really feel like this - to X448. The GnuPG FAQ als gives a rationale why larger keys are not useful.

I noticed the Debian bug and was about to answer but a feature request is also a good thing.

I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.

Sorry, it was my fault building the test installer.

We tested with Kleopatra:

• Only gpg4win 4.2 is affected (the current version) but 4.1 is not affected.
• No vsd version is affected.

FWIW, I am already working on this.

Regading Kyber in GnuPG, there are a couple of open questions. For example whether the implicit lengths used for the key parameters match well with the overall protocol structure. Thus, as soon as we have finished the Libgcrypt part we will address this and implement it in some way. Before we do this we have to do a couple of changes to GnuPG required for FIPS compliance.

Example output:

Tested with 2.4.4 beta and the problem shows only up with the parameter file but not when using --expert-full-gen-key or --quick-gen-key. The problem seems to be that the v5 flag is not enforced when using the parameter file. Thus the key is created as v4 key despite that we want to use v5 for the new x448 keys. It is not a severe bug becuase the key will work anyway using software supporting X448. Will of course be fixed for 2.4.4.

Interesting. I need to look closer at it. I scheduled it for 2.4 but it won't be in the forthcoming 2.4.4. There are still other interesting things on the short list (e.g. timestamping support) but we may do that only in 2.6.

Alright.

Thanks for the report. It comes right in time for the next release. It might already be fixed due to a lot of changes in the pkcs#12 parser.

Thanks for the report. This is the fun with different code pathes. Obviously the v5 fingerprint needs to be used for the pre-made revocation.

Ingo, what do you think?

Like this:

@@ -1196,10 +1196,25 @@ pr_string (estream_printf_out_t outfnc, void *outfncarg,
    future, when breaking API/ABI is OK, we can change signature of
    gpgrt_string_filter_t to have another argument for precision.  */
   int allow_non_nul_string = (arg->precision >= 0);
+  char *stringbuf = NULL;

We could also pass a nul terminated copy to the filter function in pr_string.

Now you can untar and run

Noteworthy changes in version 0.3.2 (2024-01-12)

The extra option --debug-allow-pin-logging was implemented with commit rGe43bd2a7a78.

Way to late for a change and also adding another algorithm (SIV) complicates things for no good purposes.

Tested this some time ago.

Better don't remove your entire ~/.gnupg - removing the *.lock files after gpgconf -K all is sufficient.

This either requires an updated libassuan which allows "INPUT FILE=foo" in addition to INPUT FD=n" or using custom handlers in for INPUT et al. in gpgsm. I'd prefer the former. Anoter option would be to open and close the file in ggpgme and pass the fd.

Already done with rG89c7eccba51554 which will be in the next VSD release.