On Sun, Mar 29, 2015 at 4:51 AM, Carlos MartÃn Nieto <c...@dwim.me> wrote: > On Sat, Mar 28, 2015 at 09:59:57PM -0700, Philip Guenther wrote: >> On Sat, 28 Mar 2015, Carlos Mart?n Nieto wrote: >> > I?ve been looking into making libcrypto automatically thread-safe. The >> > obvious solution is to use pthread to perform the locking instead of >> > relying on the user to set locking callbacks, as the final user >> > shouldn?t need to care that LibreSSL is involved in the dependencies at >> > some level. >> >> Well. How far is our reach on this? >> >> Solving this just for LibreSSL on OpenBSD? I guess you diff works, though >> it doesn't work when libpthread can be loaded after startup as the >> bindings won't be updated. If the goal is just this, then application >> writers in the wider software ecosystem won't even notice and will have to >> continue to use the callbacks, etc. > > Fixing this in LibreSSL (even if on all supported OSs) rather than in > OpenSSL certainly gives this less reach, but as LibreSSL is a lot more > focused on what it wants to support, it makes the implementation for > this much less problematic.
Today in LibreSSL portable, we already either link -lpthread, or the target OS has some sort of mutex support already factored into the C library directly. I'd be in favor of just always having the mutexes enabled. We're already unconditionally enabling mutexes in arc4random - this is not much of a stretch. I think it makes sense to make some parts of libtls independently threadsafe too, such as tls_init.
