I found that FreeBSD also requires -lpthread thing. I also commit the change to the repo.
Tested with FreeBSD 11.0.
I think that TrueOS can be considered as FreeBSD variant.

Fixed in the repo for DragonFlyBSD 4.8 too.

In T2998, NetBSD was fixed.
I'll check for DragonFlyBSD.
IIUC, FreeBSD and OpenBSD has no issue.

It works for me on NetBSD 7.1. Please test.

I tested with NetBSD 7.1 and -lrt is not required.
Nevertheless, it would be required for older NetBSD, so I leave -lrt check for NetBSD.
I'm going to push the change of D415 now.

Could you please look at https://dev.gnupg.org/T2998 ?

I think that NetBSD also defines single thread version of pthread_* functions in
libc.
How about attached patch in configure.ac?
(You need to generate configure)

D415: 990_npth-netbsd-20170328.diff

It seems that -lrt is required on NetBSD.

Oh yes, then we should include NetBSD at least into the nPth and libgpg-error
builds.

NetBSD has its own pthread library (different from OpenBSD and FreeBSD), so I
think this would be a good idea.

Our jenkins has no problems building nPth for OpenBSD 6.0.
wiz: Do you think that NetBSD (x86 I assume) is much different than OpenBSD so
that we would benefit from adding NetBSD to our Jenkins builds?

gniibe: Do you have time to look into this?

Fixed in 1.3.

Indeed, I confirm that the newly updated version 2.1.16 fix this issue, thanks a
lot for doing this portability work!

It has been confirmed that 2.1.16 solves the problem.

The reason for the crash is that 2.1.15 is calling gpgrt_set_syscall_clamp
before nPth is initialized. The nPth initialization was changed in 2.1.15 so to
solve problems on some other platforms.

uldis: Thanks for your comment. Let me show my opinion.
There are three ways (at least) to create a semaphore.
Each has different semantics, how it can be shared among different processes.

(1) sem_init with pshared=0: Not shared among processes
(2) sem_init with pshared=1: Shared among children processes of particular parent
(3) sem_open: Shared among any processes (with relevant permission)

For AIX, npth doesn't work well with (1). You suggested (3), while I proposed (2).
It is true that (2) and (3) would open up some attack vector(s),
but I believe that (2) is smaller, if any.

Sorry, I might be wrong about in previous comment. I am not sure if pshareds=1
opens up some vulnerability hole.

pshared=1 will not work on AIX for FORKED processes. It works only for threads.

Thank you.
I think that it's better to use sem_init with pshared=1.
I'm sending my proposal patch to gnupg-devel.

D361: 779_npth_broken_sem_init.patch

Given how long it has been since this bug was reported, the request for more
information and the lack of response, I'm going to mark this issue as resolved.

We need more information to triage this bug.

Libgcrypt 1.6 will be released this year.

Fixed in the git master branch.

Even if that function is never called on Android, it will need to be #ifdefed out
in order for that code to build for Android. Right now, linking fails because it
can't find the symbol pthread_atfork.

Thanks for information (Note: I don't have experiences for Android).
I realized that fork/exec is basically not supported for applications on
Android.
If this were true, it makes sense to ifdef-out the calls to pthread_atfork for
Android.

The reason why we need to call pthread_atfork is to reset signal mask for
executable fork/exec-ed by the program. We had a bug which stoped killing
pinentry (which was fork/exec-ed by gpg-agent).

Its also not in any headers in the NDK:

$ grep atfork /opt/android-ndk/platforms/android-*/arch-arm/usr/include/*.h
$ grep atfork /opt/android-ndk/platforms/android-*/arch-arm/usr/include/*/*.h
$

Bad news, though that .c/.cpp file exists, it does not seem to get built into
Android. I have tried building against android-14, which is after that file was
introduces, and no luck. I also tried looking for it in the libs, and its not
in the .so or .a libs. Running this gives me nothing:

$ strings /opt/android-ndk/platforms/android-*/arch-arm/usr/lib/* | grep atfork

we've decided to suspend support for older versions on Android, so we can leave
this as is for now, any maybe forever. We want to support older versions, but
its more work than we can handle. Patches are welcome though, if anyone wants
to add back support for Android versions old than android-14/4.0/Ice Cream Sandwich.

It looks like pthread_atfork() was not added to bionic libc[1] until after
android-10/v2.3.6/Gingerbread. That excludes 1/4 of current Google Android
users, and probably more of unoffical Android users.[4] To target older
versions of Android, you either have to include pthread-atfork.c[2] or the newer
[pthread_atfork.cpp][3] in your project, or not use pthread_atfork() at all.
We might be able to manage including pthread-atfork.c, but it could be ugly.

[1]:

https://android.googlesource.com/platform/bionic.git/+/4f086aeb4aa06e13079b7fec71a8178ceeacf318

[2]:

https://android.googlesource.com/platform/bionic.git/+/android-4.0.1_r1/libc/bionic/pthread-atfork.c

[3]:

https://android.googlesource.com/platform/bionic.git/+/master/libc/bionic/pthread_atfork.cpp

[3]: https://developer.android.com/about/dashboards/index.html

I checked the source code of Bionic libc. There is the function defined:
https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_atfork.
cpp

Is it compile time option not including this function?

We will address this in 1.6. At least for ELF systems supporting the weak
pragma and for W32.

Fixed in commit 62842cc for gnupg master (2.1)

Hmmm, I'll do a test tomorrow.

FWIW, pth_connect is part of the regular interface.

It is okay for one request to take a long time or possibly even to block.
But it is not okay, if other, simultaniously made requests are blocked to wait
for this slow request. Especially if those parallel requests could be answered
easily and quickly, like ping.

If you ask to download a large CRL and the server is slow it takes time. If you
download a webpage with a lager image and the server is slow it takes time. The
solution is to cancel the request.

To me this, issue makes dirmngr unsuitable as a system service
and it currently allows denail of service attacks on gpgsm based email
applications.

Fwiw, the name of the new thread implementation will be npth.