Won't be fixed for the creation thing.

This is the old code from gnupg-2.0/agent/gpg-agent.c:

inotify is already used used on Linux to check for a lost homedir. The once-in-a-minute check should be the same as with the other daemons and has proved to be very useful. The whole thing has been discussed over and over again a long time ago and - as with other system daemon - we agreed on scheduling at the full second.

aheinecke: Yeah, but I did quite some changes to build.sh for a real out-of-source build (w/o copying files)

No real world bug reports for this and thus a backport has a small risk of a regression.

Thanks for that info. I tag it as FAQ and change the subject in case someone searches for such a problem.

The compliance mode likes 4880 or 2440 are only here for backward compatibility in case that is needed. New keys shall always be generated using the current default algorithms. Note that a mode like de-vs is different in that it is used to comply with certain regulatory demands and not as a backward compatibility hack.

Fixed in master and the new gpgme-1.24-branch. Thus this fix will be in 2.0.0 and 1.24.2

Sorry, this will not be fixed for 2.4.

I am pretty sure this was my fault: rM62b6c1f16 is the culprit.

@gouttegd: Good idea. I did this with the above patches.

FWIW, If a fix is really required for gnupg this will be done for gnupg26 and not for gnupg22. However, it is mostly a kleopatra issue.

Thanks. I applied all 4 patches to master and did one additional change to get --allow-old-cipher-algos straight.

I never tested the WSL stuff with gpg-agent but I use the standard OpenSSH based ssh server on Windows on a daily base. It is actually part of our release build chain. A recent problem I encountered was fixed in master with rG2469dc5aae and should be backported to 2.4. Might be related to your problem but I need to read your detailed bug report more closely.

That gpg seems to be some other or patched software than the one from gnupg:

Signs from the past or is this due to fixed Observer URI I did this morning in this repo?

gpgconf assumes that there is only one of the daemons. In fact it can only work with one and that is the one daemon which listens on the socket. all daemon's do a self-check by trying to connect to themself and terminate if they realize that they are not anymore the owner of the socket. As long as a daemon is started by a gnupg component a file system lock is taken to avoid duplicate launching. However it a daemon is stared by other means this could lead to a race.