No test environment in our QA dept.

Fixed in 2.4.4. Feel free to re-open if you still see problems.

No regression, assuming things work.

Hard to test without instrumenting the code.

Tested during development.

Tested for 2.4

@alexk and me tested this. The core functionality works.

Fixed in 2.4.4 and 2.2.43 - see above for affected versions.

Works for the two sample RSA cards. Ticket may eventually be re-opened if we run into problems with ECC cards.

Fixes are already in GnuPG 2.4.4 and can't be easily tested. Thus closing also for gnupg24

Closing because we believe things are fixed and our test suite confirms that. Feel free to -reopen in case your own file does not import with 2.4.4.

The test file is now part of our test suite and passes.

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.