I pulled that branch with the commit w/o problems. However, as noted on your commit I won't apply that because it does not make any sense to change boilerplate blurbs for just an additional 's'. Nobody really uses that and browser can try to use https first. Sorry, there are more important things around.

(hm, i'm pushing apparently successfully to playfair.gnupg.org:/git/libgcrypt.git but it is not showing up here. if you want to fetch this patch, you can also find it on the http-to-https branch at https://gitlab.com/dkg/libgcrypt.git

I would prefer not to fix that. I did some experiments on replacing all the runtime parsed ECC constants by static data. Adding the other constants will then be simple.

I've prepared patch for statically defining mpiutil contants, but I can leave it out and not push to master.

I was talking to Thomas Dickey, who maintains Ncurses. Ncurses had a leak and he offered a config option to remove it. Ncurses config responds to --disable-leaks.

Dynamic loading of Libgcrypt is anyway not supported; those who do that are on their own.

I have not yet looked at the details but I do not consider one-time allocation a problem. If you want to silence ASAN it is possible to use gpgrt_annotate_leaked_object( foo). Dynamic loading of Libgcrypt is anyway not supported; those who do that are on their own.

That type of variadic macro is GCC extension, see https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

The second and third arguments passed to xgcry_control seem to be lost when calling gcry_control.

Here are the next two failures I am seeing while testing libgrcypt. It appears to be related to GCRYCTL_INIT_SECMEM.

I'm still seeing a few odd outputs from make check, but I have not investigated them yet.

Maybe cleaner option for mpi/mpiutil.c would be to statically allocate the constants

Maybe cleaner option for mpi/mpiutil.c would be to statically allocate the constants

Here's a couple of awful hacks that get me through make check. Feel free to restate how awful they are; I know it is a bad thing to do.

SPARC T4 has crypto instruction set for AES, GCM, SHA1, SHA256, SHA512, Camellia and DES, that can be used from user-space too.

Isn't the Sparc crypto instruction set only available in kernel mode?

This change has been pushed to repository.

I think commit https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=09c27280cc09798d15369b3a143036b7ab5ddd69 should be backported to 1.8 branch of libgcrypt.

Thank you, it worked.

Thanks.

Applied to master. This is not suitable for 1.8

for whatever reason, i don't seem to be able to push to the branch on playfair, so i've also pushed the same commit over at https://gitlab.com/dkg/libgcrypt

Fixed in master.

Thanks for your report.
I think that your patch is too generous to run HMAC even if fips_mode is not enabled; Simply, we can stop calling integrity check when fips_mode is not active.

Reading https://en.wikipedia.org/wiki/Fedora_version_history, I guess that your kernel/glibc doesn't have working mlock.
It may work if running by root, though.

T4298: 'make check' with uninstalled library, which is building now (even if rpath doesn't work well) handles related issue, which was fixed for libgcrypt-1.9. Since this issue is for other libraries (libgpg-error, specifically), we could do something similar, but, it may be detecting LD_LIBRARY_PATH to fail with "Please remove LD_LIBRARY_PATH".

Applied.

Pushed to master, fixing about return value of getentropy. Tested on FreeBSD 12. Tested on FreeBSD 11 where getentropy is not available.

All right then, fine by me.

These are hooks so that co-operative thread libraries (like ntph) are able to yield control to the system's thread's implementation.

Sorry for long reply, your change looks ok even though dunno it is meaningful those _gcry_pre_syscall ()/_gcry_post_syscall () surrounding get entropy for example.

I give this normal priority to move it out of the "Needs Triage" queue.

Set to high because it breaks a build.

Done for libgpg-error.

Topic branch of libgpg-error is not good to show changes (for other libraries).
So, I made D473: Introducing LDADD_FOR_TESTS_KLUDGE to enable 'make check' with LD_LIBRARY_PATH.
Appliying to libgpg-error.

For other distros, it seems it's quite old issue: https://sourceware.org/ml/binutils/2012-05/msg00037.html

My patches on the topic branch: https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fdisable-new-dtags/

In my patch, for OpenBSD and FreeBSD (well, other than GNU/Linux), it uses getentropy if available. For GNU/Linux, we use the local macro of getentropy (regardless of the availability of the function), keeping exactly same behavior of syscall with __NR_getrandom.

Update to prefer syscall on GNU/Linux (no need to audit libc implementation):

My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.

This is mine:

Confirmed my theory of getentropy(3): https://reviews.freebsd.org/rS331279

Reading this discussion: http://lists.gnu.org/archive/html/bug-libtool/2018-01/msg00014.html
It seems that it could be fixed if we care about the order of libraries.
And it's not the issue for libgpg-error, which doesn't require external libraries.

For binutils, in Stretch, Debian specific patch was introduced.
Then, upstream introduced --enable-new-dtags option for configure to build binutils.
Now, Debian uses --enable-new-dtags option (at build time).

I think we should stick with the syscall for Linux.

OpenBSD uses getentropy(2). glibc (>= 2.25) has getentropy(3), too.

For the correctness of rndjent implementation, I'm applying D461: jent random requires finalizer to deallocate secure memory.

Perhaps, it's better to remove -no-install flag in tests/Makefile.am, so that test programs will be wrapper script by libtool.

See T4293

With GCRYCTL_AUTO_EXPAND_SECMEM we won't anymore run out of secure memory. This has even silent been backported to 1.8.x (using the numerical value of that constant) and is for long an option of gpg-agent. Thus closing.