oops: That was an accidential priority change
The mentioned "strange hangs" would only be solvedwhen using master - in 2.2 we already had proper locking.
Implemented master and 2.2. Note that the comment in the master commit about possible reason for stucked keylisting in gpgsm is only related to master.
I implemented it nearly as suggested. However, the default AKL is used, which is "local,wkd" (local is not used with that command though).
Fixed for 2.2.18. To allow seeing these warnings this change will only have an effect if a listing of all keys is requested.
Done for 2.2.18
This was already fixed with version 2.2.5.
Will be in 2.2.18
I changed the suggestion to read:
The agent is an important part of gnupg and it does not make sense to single out cases when it might not be needed. I can't see any harm from having an agent running. In fact, one of th netxt versions will add yet another daemon which will then be needed in all cases.
Thanks, @gniibe. From reading this patch (i haven't tested it), it looks like it would avoid most unnecessary agent launches (and agent communication) in the (b) case, which is a win over the status quo.
Note that rGd3f5d8544fdb needs to be backported to 2.2 but we will wait until we have better tested it.
With me it happens all the time: Outlook 2013 x64 is half-maximized at
right border, and GPG asks for the passphrase on sending a mail from the
inline editor, on Windows 7 x64, then it always happens.
Fixed in master.
This part of code is questionable. It always comes fp!=NULL, so the part should be removed.
If fp==NULL, use of tmpfile is quite questionable because a user can't know where the trace output goes.
I'm going to remove that part.
If it makes sense to warn a user for someone's preference when keys are imported,
here is a patch:
It appears (for me) correct behavior.
Wed, Aug 21
This was also raised for (hopefully) wider discussion on the IETF mailing list.
i've just pushed rGc4b9eba1d6a63b73238dcbb644b365dc53563f3d to the dkg-fix-T4682 branch resolve this.