Excuse me you are right of course. man gpgconf | grep quot says it all.

man gpg | grep quote nor man gpgconf | grep quote does not tell anything about it. I recognized the single opening quote of "string at post processing the output of gpgconf --list-options to generate a gpgconf.conf template. I just expected a closing quote for "string".

vitusb: We had this discussion on cryptography@ years ago. No need to start it again - or well, try it over there. This is a bug tracker and not a discussion forum.

These curves are not the default in the compliance mode "gnupg" only if you explicitly switch to the BSI defined "VS-NfD" mode they become default.

Nope. The double quote indicates a string. See the man page.

In T5783#153879, @werner wrote:

Sending a private key with just the local protection is not a good idea.

In T5784#153872, @werner wrote:

Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.

Sending a private key with just the local protection is not a good idea. It is better to export the key and then send it in an encrypted mail - for example in symmetric mode with a strong password.

Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.

That is a security feature of WIndows. We can't do much about it except for bad hacks. Checkout Kleopatra to see how you can improve this.

The first is a warning and the other error codes are exactly what we want.

Not a bug but a limitation of 2.2's option listing: In contrast to 2.3 we can't *show* the used options via gpgconf correcly if there is a conflict between global and local options. However, the actually *used* values are different and correct according to the config. In particular a global forced option overrides any local or command line option.

Just adding this note because a next step I'm also evaluating in my current T5593 configuration status it to temporarily create a new Gpg4win 3.1.16 hybrid configuration by also adding latest GnuPG v2.2.31 to see if all issues I reported here are still present (which is also quite probable).
Also because of T5593 it would just be quite interesting to see if GnuPG v2.2.31 too might experience same T5593 path related error.

Hi Werner,

Sure they don't get created - they are optional.

Just tracking my own additional investigation still about past Werner statement "percent escaping is correct and required" when this bug was closed for 1st time.
Also found interesting past references into rG055f8854d3f4 and rGe064c75b08a5 but only this last seems indeed much more specifically directly involved since it really contains related part of code (common/stringhelp.c) directly involved with this bug report for 'percent escaping' ':' (colon) character with '%3a' string even if sometimes, when possibly un-needlingly done, may even provide users unexpected on-screen displayed results like those I documented in this bug.
Problem now is that to really fully understand why on-screen displayed strings by 'gpgconf --list-dirs' correctly show a ':' (colon) correctly expected character near an unexpected (by end users) '%3a' (percent escaped) string that should just have corresponded with another simple (& user correctly expected) ':' colon character I can only really see to 2 options:
A) reopening this bug once again :-S ;
B) simply opening a new separate one asking for some additional explanations and maybe even to consider some future slight code changes to (at least for Windows OSes) ensure 'gpgconf --list-dirs' directory displayed paths results are more UI consistent with 'gpgconf --list-dirs homedir' or 'gpgconf --list-dirs sysconfdir' displayed ones where displayed C:\... paths always correctly display ':' (colon) instead of '%3a'.
So far this last seems me best viable option also because in same rGe064c75b08a5 I also saw another piece of code (tools/gpgconf-comp.c) with some similar code lines, that apparently (it seems me) if directly referenced (at least only for Windows OSes only, so maybe when a system variable %OS%==Windows_NT exists) instead of current one (common/stringhelp.c) also providing '%3a' 'percent escaping' results, might then have probably also easily avoided '%3a' user unexpected on-screen displayed results only depending by 'percent escaping'.

Just adding this note for any future reference needs only (or even message localization reference, since involved text characters strings are also expected to be among Italian language localized messages even if involved strings are not specifically being localized).

Hello Werner,

That's correct - The output needs to be percent escaped.

wk at gnupg dot org but better avoid any HTML parts etc.

Thank you, this is my great honor!
If it is convenient, can you provide an email address? So that I can elaborate to you.

Thanks. I added it to the list. If you have not yet done this I would suggest to write a note to gnupg-users.

The surprising thing is that it works at all. I wouldn't be surprised if certain would simply reject it as "not a pdf" given that the "%PDF-1.x" marker isn't at the beginning.

--clearsign may only be used for plain text documents due to line ending conversion etc.

See the release notes for GnuPG 2.2.17 (T4606 first item). You need to import your peer's signature from a different source; e.g. ask them to send you your signed key by mail.

The log file specified in .gnupg/dirmngr.conf is created at the start of dirmngr.
dirmngr is invokded by the first call of gpg, and it keeps running and handle next request from second invocation of gpg.
So, nothing is problem.

You used custom options which did not pick up the proper libksba. Install libksba correctly then try again. Please direct further questions to the mailing list and please build the latest version 2.2.23 and not an arbitrary old version.

The CRL states how long it is valid and we cache it for about that time.
OCSP responses are by definition not cachable but we allow for a clock skew of 10 minutes.