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.

Closing, given that we implemented a general solution; see the parent task.

I have seen no responses on your two mails to the ML and given th athere is no concrete protocol bug, I close this issue. If you can show a concrete bug please re-open this issue again.

Apparently, it's an error from your installed /usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib (you have some configuration to prefer this library), while your configure is for /usr/local/lib (because you specify no --prefix).

In FreeBSD, getrandom(3) became available, when getrandom(2) was added. <-- This is my theory.
If this is true, just use getrandom(3), not using getrandom(2) by syscall.

Adding the patch here.

T3530 describes the solution. In short: Put "auto-expand-secmem" into gpg-agent.conf.

Thanks. Just pushed the change to master.

The corresponding fix can be found here: https://github.com/smuellerDD/jitterentropy-library/commit/9048af7f06fc1488904f54852e0a2f8da45a4745

Please note that this issue in Jitterentropy has been already fixed by upstream: http://www.chronox.de/jent.html

Hi sorry, here it is. I don't see a recommended way for providing a ton of text, so just pasting it here.

Please provide a complete build log or at least the output of the configure run.

IIUC, in Gentoo multilib (or other distributions), <triplent>-{gpg-error,libgcrypt,libassuan,npth,libksba,npth}-config script is used.
In forthcoming libgpg-error 1.33, single gpgrt-config is used for all architecture, by having --libdir option at invocation time.

New gpg-error.m4 detects gpgrt-config, too.
And configure supplies --libdir when it invokes gpgrt-config.
For other *.m4 (libassuan, ksba, libgcrypt, ntbtls), it is possible for them to check GPGRT_CONFIG to use gpgrt-config if any.
For npth.m4, it can do that too, with no hard dependency to libgpg-error.

Fixed in master and 1.8.
@dkg: Thanks for the comments and your patience to convince me.