Related the changes, before we did the changes, we received two independent reports.

I am not sure whether this is related but when using Libgcrypt master and verifying a signature created with an ed25519 key, I get the error below with valgrind. Both with 2.2. current and 2.3. It does not happen with the current Libgcrypt 1.8.

Fixed in master.

A program like tests/t-mpi-point assumes gcry_mpi_print can do that.
We have a sort of regression with --debug option with t-mpi-point, the point q is not printed out correctly.

This requires re-evaluation of Libgcrypt to match the current FIPS specs.

Thanks for reporting this this. Your patch is correct.

Regarding Cygwin: The sources are a bit hard to find.
https://cygwin.com/packages.html
-> https://cygwin.com/packaging/repos.html
-> https://cygwin.com/git-cygwin-packages/
-> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/libgcrypt.git;a=summary

Regarding GNU/kFreeBSD, my machine is using the FreeBSD 9.0 kernel, which does not yet have the security.bsd.unprivileged_mlock oid. Like what was mentioned here: https://lists.debian.org/debian-bsd/2014/08/msg00092.html

For Cygwin, I can't find how its libgcrypt package is built.
I found this for MSYS2: https://github.com/msys2/MSYS2-packages/tree/master/libgcrypt
This for Mingw-w64: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-libgcrypt

I tested on FreeBSD. Same errors (t-secmen and t-sexp) are reproducible when we set:

On Solaris, the test errors are because of:

USAGE
       Because of the impact on system resources, the use of mlock() and
       munlock() is restricted to users with the {PRIV_PROC_LOCK_MEMORY}
       privilege.

OK, I identified the problem on OpenIndiana. The inclusion of <unistd.h> causes inclusion of <sys/types.h> before config.h. I'm going to fix this.

Patch have been applied to master, https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=79ed620ec46adbb08f5cea6a4865a95a436e4109

Yes, I need to optimize it.

@jukivili thanks for looking into this. If you want, you can go with "Marvin W. <git at larma.de>" or just keep as is.

Hi @slandden. Have you made any progress since the last time I asked?

For GNU/Linux or GNU/kFreeBSD system, libgcrypt 1.8 with libgpg-error 1.36 has no problem in Debian build:
https://buildd.debian.org/status/package.php?p=libgcrypt20

In solaris11openindiana-log2, we have two errors: one for ulong, and another for ushort.
I fixed the former. It is because of our mistake of using ulong before it is handled by libgcrypt/src/types.h. In the first place, it is implemented by "unsigned long", so, there is no need to use ulong here.

Thanks for bug fix. I've prepared patch and send it to mailing list https://lists.gnupg.org/pipermail/gcrypt-devel/2020-January/004885.html. Let me know if Reported-by is ok/enough. I would have liked to put you as author of commit, but this Differential interface of quite horrible and does not give all the needed information (mainly "name <email>" format for git).

It looks good.

Oh, no worries! Just wanted to confirm, that's all.

I am about half way. Sorry for the slowness.

I've been wondering this also. I can start working on this.

Hello,
Is anyone working on this? Just want to confirm.

El vie., 8 nov. 2019 8:19, johnmar (John Martinez) <noreply@dev.gnupg.org>
escribió:

Allow me to clarify. For bounty purposes, as long as the intrinsic implementation matches or beats OpenSSL performance, it is acceptable. There have been cases where the use of certain intrinsics may yield better performing, but sub optimal results.

Please note that C-based intrinsic implementation is the way to go now as that is the path chosen for PowerPC implementations in libgcrypt.

C-based intrinsic implementations are discouraged.

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.

Check out the mailing list gcrypt-devel@

Folks, I was just wondering if I could get an update on where we are with this bug. It seems we aren't sure if it's a real issue or not. What's the latest thought?