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.

This is due to the changed format of the VERSION file.

I applied a fix to gnupg which also solves the issue.

We did this on purpose once - For Windows ppl it is just weird to see forward slashes.

Double backslash quoting is the culprit. For WKD requests the GPGMe QT code makes sure that the dirmngr has been started. This is done by running gpgconf --homedir FOO --launch dirmngr. gpgconf returns the homedir with backslashes on Windows to be be nice to ppl who wonder when they notice (legal) forward slashes on Windowns. Now when the spawn function along with its helper is called, it needs to quote the backslashes. But somewhere on the way back one de-quoting is missing and thus gpg sees double backslashes. That is in general not a problem but when checking whether this is the standard home directory, this does not match and gpg puts the socket into a subdirectory. In turn another dirmngr is started for the WKD purpose.

Yeah we should do an ntbtls release. As a core library it does no matter much which workboard we use. Let's remove it the vsd tag.

It does not matter how many gpgsm instances try to start a daemon. The same code is used for starting and this code first takes a lock. When using gpgconf --launch the same code is used too (indirect by calling gpg-connect-agent NOP /bye wityh options for the respective daemon).