Please read my answer again. Posting to gnupg-users does not require a subscription.

Please do not force me subscribe to yet another mailing list to see the answer.
So do you have any plans to make new release? :)

See T4683 and T4684.

I'll start working on PowerPC GHASH implementation in September after SHA2 is done.

I'll start working on new PowerPC SHA2 implementations for libgcrypt in coming weeks.

Patches for PowerPC AES acceleration sent to mailing-list, based partly on initial work by Shawn Landden (@slandden): https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004788.html

It has now been more than a month since:

And also this is excellent point.

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.

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.

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.