On 24. jan. 2018, at 6:11 f.h., Benjamin Kaduk via openssl-dev <openssl-dev@openssl.org> wrote: > On 01/23/2018 07:19 PM, Salz, Rich via openssl-dev wrote: >> Well, the most likely fix is to make the “safely” wording be more vague, >> which I doubt you’ll like. But I doubt anyone on the team has much interest >> in fixing 1.0.2 locking issues. > > Who said they were 1.0.2-specific? Master's obj_dat.c still has a completely > unlocked OBJ_new_nid() that is a public API function; AFAICT the issue is > still present.
As you say, this really doesn't seem to be a 1.0.x-specific problem. The current development tip on github has the same issue (and the same language in doc/man3/CRYPTO_THREAD_run_once.pod). The current patch ( PR 5164 ) just changes "can be safely used" to "can generally be used safely". Without enough information for a user of the library to know whether a given usage is safe, this isn't useful documentation. When it comes to threading, "generally safe" is the same as "unsafe". There needs to be at least a little bit of guidance. A quick check of my system's openssl 1.1 libraries shows 280 mutable global variables in libcrypto and 36 in libssl. Most of those are presumably protected by locks or are only set during init; for the remaining actual thread-unsafe variables, it should be possible to document the small number of APIs which affect them.
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
