The mentioned "strange hangs" would only be solvedwhen using master - in 2.2 we already had proper locking.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 23 2019
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.
Aug 22 2019
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.
Thanks.
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.
Aug 21 2019
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.
@dkg, I changed the title and adjusted the description to more accurately describe the situation.