Re: About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c
Wim Lewis <[email protected]> Wed, 24 Jan 2018 15:45:57 -0800
| Newsgroups | gmane.comp.encryption.openssl.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============3957533212298257092== Content-Type: multipart/alternative; boundary="Apple-Mail=_EDDD2279-CE97-4ACE-93AF-C3A6BFB8BD5F" --Apple-Mail=_EDDD2279-CE97-4ACE-93AF-C3A6BFB8BD5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 24. jan. 2018, at 6:11 f.h., Benjamin Kaduk via openssl-dev = <[email protected]> wrote: > On 01/23/2018 07:19 PM, Salz, Rich via openssl-dev wrote: >> Well, the most likely fix is to make the =E2=80=9Csafely=E2=80=9D = wording be more vague, which I doubt you=E2=80=99ll like. But I doubt = anyone on the team has much interest in fixing 1.0.2 locking issues. >=20 > 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. --Apple-Mail=_EDDD2279-CE97-4ACE-93AF-C3A6BFB8BD5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;" class=3D"">On 24. jan. 2018, at = 6:11 f.h., Benjamin Kaduk via openssl-dev <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:<br = class=3D""><blockquote type=3D"cite" class=3D"">On 01/23/2018 07:19 PM, = Salz, Rich via openssl-dev wrote:<br class=3D""><blockquote type=3D"cite" = cite=3D"mid:[email protected]" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);" = class=3D""><div class=3D"">Well, the most likely fix is to make the = =E2=80=9Csafely=E2=80=9D wording be more vague, which I doubt you=E2=80=99= ll like. But I doubt anyone on the team has much interest in = fixing 1.0.2 locking issues.</div></blockquote><br class=3D"">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.<br class=3D""></blockquote><br class=3D"">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).<br class=3D""><br = class=3D"">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.<br class=3D""><br class=3D"">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.<div class=3D""><br = class=3D""></div><div class=3D""><br class=3D""></div></body></html>= --Apple-Mail=_EDDD2279-CE97-4ACE-93AF-C3A6BFB8BD5F-- --===============3957533212298257092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev --===============3957533212298257092==--