See https://minerva.crocs.fi.muni.cz/ for a description of the timing attack.

I modified _gcry_ecc_fill_in_curve so that g_y has new value in eid4730.

That's my badness. I think that I haven't seen this problem, because I mainly use tokens (where keygrip difference doesn't matter, after --card-status).

Poly1305 addition helper for ppc64 posted on mailing list: https://lists.gnupg.org/pipermail/gcrypt-devel/2019-September/004804.html

PowerPC SHA-256 and SHA-512 implementations with little bit more tuning committed. Most notably, SHA-512 on POWER8 now gives similar performance to OpenSSL:

... https://lists.gnupg.org/pipermail/gcrypt-devel/2019-July/004760.html

Patches send to mailing list:
https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004800.html
https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004799.html

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

Fixing t-lock is indeed a better solution however having an option to disable tests could be used in another context than fixing this issue.
For example, in the context of buildroot (which goal is to build a custom embedded linux system), this option could be used to save time during compilation as well as to save space on the embedded system.

Thanks for your report.
I think that adding an option for disabling tests is too much.
If it were AC_SUBST, we could use HAVE_PTHREAD in tests/Makefile.am.
In the current situation, just modifining t-lock is easier.

@werner I would be willing to share 20% to the reviewer of my patches. (or 25% in this case, as @jwilk went through the effort to even write a test to point out a bug in my code). However, so far that has been entirely @jwilk who has been reviewing my patches.

Please STOP adding such bug reports or feature requests. They are not helpful and such discussion are better done at the mailing list. In case you want to spend money to speed up things you may contact gnupg.com for a quote.

Please do not change the priority back. That is a maintainer's task. I consider this along with adding replicas of issues to a bit rude.

Please do not change the priority back without discussing this with the maintainer first. Thanks.