> The key is to acquire resources in places that can fail and use them in places that can't. I'm amazed and disappointed that the LibreSSL people aren't following this basic principle.

Wow, great find! LibreSSL could avoid this by calling the getpid() syscall directly.

> Any idea if direct calls to clone(2) also bypass pthread_atfork?

They do, since atfork handlers are invoked by the userspace wrapper for fork().

> They do, since atfork handlers are invoked by the userspace wrapper for fork().

I don't think user libraries should try to deal with users subverting the facilities on which they rely. There are defined interfaces to system functionality. Break or bypass these interfaces, and you're on your own. If you subvert the usual API semantics by calling clone(2) directly or bypassing the fork(2) wrappers, you should be cognizant of the implications.

It would not be unreasonable for a runtime or VM (like a JVM for example) to use a native library for TLS (performance reasons). It would also not be unreasonable for a VM to use clone() directly, maybe it's part of how it implements its own threading or co-routines for example.

Combine those two reasonable patterns with LibreSSL, and suddenly you have a vulnerability. This is even more likely when you take into consideration that LibreSSL is intended as a direct replacement for OpenSSL; callers are even less likely to examine the fine print of the documentation for undefined and unsupported behaviour.

Still, the LibreSSL work is commendable and should be appreciated. The real problem is a lack of good regression tests - and there may be a messy future of niggly issues because of that. I've already had to deal with some.

I'll give another tricky example. One of the earliest pieces of functionality LibreSSL ripped out was an in-library DNS cache. It was poorly documented and the assumption was that it was there as a crutch for shoddy OS-level DNS caching. But I think this cache also played another role; it helped certificate validation workflows function. Sometimes endpoints bind different certificates to different IP addresses for the same DNS-name that uses DNS-level load balancing. If you don't make the name resolve to the same IP address consistently, then what can happen is that the first connect() gets certificate "A" and some user-facing UI or validation process authenticates it, but then then another connect() gets certificate "B" and the caller logic gets confused.

Of course we could blame the caller; or the folks mixing certificates for the same name, but it doesn't really help; users still experience these problems. Just one example of why it is very hard to remove code in fully backwards compatible ways, even if the change seems very innocuous.

There is a test for this in the test suite so you get a warning.

I would agree, were LibreSSL designing its API from scratch. The problem is that OpenSSL's API provides a way to explicitly reseed the PRNG, so a programmer doing something nutty like bypassing the fork() wrapper has a way to make sure the PRNG is still safe to use. If LibreSSL wants to be a drop-in replacement for OpenSSL, its API needs to provide the same functionality.

Edit: to be clear, none of this is an argument against using pthread_atfork - I just want LibreSSL to provide an explicit way to reseed the PRNG like OpenSSL does.