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.

The next step is to release libgcrypt 1.8.4 :-)

Actually we plan to provide a more convenient way to perform the DH operation. See for example P7 for the non-elegant way which is required today.

Fixed in master and 1.8 by detecting a fork and re-opening the devices

A bit tricky, but this would be good to use gpgrt-config by gpg-error.m4.
I say "tricky", because its name is gpg-error.m4 but it configure GPGRT_CONFIG to access to GPG_ERROR_CONFIG.

It might be good idea to provide libgcrypt.pc in libgcrypt 1.8.x for forward compatibility with libgpg-error 1.33.

Well, I changed my mind. Use of new gpgrt-config requires software update to introduce gpgrt.m4 and update of configure.ac to switch gpgrt from gpg-error, in standard way.
That's too much this time. It's good to defer this change.

OK, I'll change to use gpgrt-config, along with requiring newer version of libgpg-error.

Fixed in 1.8

Fixed in 1.8

yat2m updated. Thanks.

Thanks.

Thanks again.

Thanks. Not a real world problem now but needs to be fixed.

May I suggest to use a (new) gpgrt-config instead of the current name libgpg-error-config. The long term plan is to change the name of the library.

This is the dependency graph:

Thanks. Fixed in master. Needs backport.

Thanks. Fixed in master.