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 

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

Reply via email to