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. Solving this LibreSSL on all ported to platforms? Much harder: have to solve the late-loaded libpthread problem immediately, figure out what works elsewhere, etc. This goal might at least start to make a dent in developer conciousness, but unless/until OpenSSL does something similar developers will still be doing the work. LibreSSL doesn't "own" the API presented by libcrypto and libssl; we aren't the 600lb gorilla there. (So why haven't they solved it? Just an overriding desire to reduce unnecessary overhead? They have enough compile-time options, so platforms without threads won't have stopped them...) Maybe where we should fix this is libtls, which we *do* control: have libtls do the necessary callbacks... Philip
