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.

If you encounter real world certificates with these parameters we can bump up the priority.

Why do we need a word list if we are a password storage tool?

In case of build problems related to a failed test you may want to apply rEb6df311368133df90c3bf338fbf5c90bd8d950f8.

If you want to write a new thing please also consider the rendering hints gpg-agent can send to the pinentry. This is enabled if the Pineentry sends back a FEATURES sstatus tring with the keyword "tabbing".

FWIW, the original idea with Pinentry was to have a stripped down Widget which allows to securely enter the password. For that we even replaced the Gtk text widget to have better control over the code path from keyboard to screen. After a few years more more more stuff was requested and meanwhile the QT version of the Pinentry is probably larger than the gpg-agent process.

See this comment which is related to T4538:

Note: The is a bug in the gnupg-w32-2.5.3 tarballs. After untaring cd to the directory as usual but then do:

rm PLAY/src/zlib/*.[oa] PLAY/src/bzip2/*.[oa]

before you run

make -f build-aux/speedo.mk this-native