Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Salz, Rich via openssl-dev]

  *   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.

Pedantically and strictly speaking, you might be correct.  Pragmatically, 
however, many people have been able to write or deploy multi-threaded servers.

I doubt that anyone on the project will do anything approaching a definitive 
thread-safety analysis, let alone documentation.  Even with the “small number 
of API’s” that might be affected.


-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Wim Lewis]

On 24. jan. 2018, at 6:11 f.h., Benjamin Kaduk via openssl-dev 
 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

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Salz, Rich via openssl-dev]

  *   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.



https://github.com/openssl/openssl/pull/5164


-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Michael Richardson]

Viktor Dukhovni  wrote:
>> On Jan 24, 2018, at 9:27 AM, Michael Richardson  
wrote:
>>
>>> email clients are designed to handle hundreds to thousands of messages
>>> a day, Github UI isn't

> Indeed email is best for informal ad-hoc back and forth threaded
> discussion, while Github et. al. are for issue tracking.

> If there's a clear problem that requires tracking and resolution,
> then the right forum is Github.  If there's a topic to discuss,
> we have openssl-users.  Most openssl-dev threads were more
> appropriate for openssl-users.

I'm okay with taking more of the "what is the right answer" questions to
openssl-users if that's the plan.

I truly love github for many many things, but the email interface to issues
and pull requests has been a problem for me with projects like tcpdump.
I personally don't render HTML parts, and read 90% of my email via
emacsclient -nw.

Users reasonably post things. 60% are silly requests which a google search or
a "man foo" would resolve but it generates emails to the busiest people
only (the maintainers), skipping the other users on the list who *also* could
answer if they knew there was a well formed question.

Is there a stackexchange/serverfault?

I took to CC: tcpdump-workers when I answered github issues by email,
particularly when there was a question of project goals or policy involved.
I realized that there is a bit of a XSS/spam attack facilitated by doing that
as the magic reply-to address to get stuff posted to the github issue is now
happily archived in the ML!

Does github issue process the emails with useful quoting in them usefully? 
Sorta.
So, I'm skeptical, but I am willing to go with the plan.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Viktor Dukhovni]

> On Jan 24, 2018, at 1:25 PM, Dr. Matthias St. Pierre 
>  wrote:
> 
> Ok, I didn't know that. If anyone seriously participating on GitHub can
> join the moderated openssl-project list then this sounds like a good
> replacement for openssl-dev, because that list will be more focused
> and not bothered with so many misplaced posts that should have
> gone to openssl-users.

Interested participants can sign up at:

  https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Viktor.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Dr. Matthias St. Pierre]

On 24.01.2018 19:08, Viktor Dukhovni wrote:
>
> Well, but we now have "openssl-project" for discussions of the
> ongoing development of OpenSSL.  It is mostly for team members,
> but though it is moderated, IIRC others can join and post.
Ok, I didn't know that. If anyone seriously participating on GitHub can
join the moderated openssl-project list then this sounds like a good
replacement for openssl-dev, because that list will be more focused
and not bothered with so many misplaced posts that should have
gone to openssl-users.

Matthias

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Viktor Dukhovni]

> On Jan 24, 2018, at 12:55 PM, Dr. Matthias St. Pierre 
>  wrote:
> 
> As for the two mailing lists openssl-users and openssl-dev: It was always
> my understanding that the former was for usability questions starting
> from newbie questions up to very sophisticated subjects, whereas
> openssl-dev was for discussion around the development process itself.

Where "development process" means development of OpenSSL itself, not
software dependent on OpenSSL.  Since openssl is primarily a developer
toolkit, not end-user software, the openssl-users list is really for
developers, just not developers of OpenSSL itself.

> If we agree that mailing lists are preferrable to GitHub threads, then we
> should not close down openssl-dev.

Well, but we now have "openssl-project" for discussions of the
ongoing development of OpenSSL.  It is mostly for team members,
but though it is moderated, IIRC others can join and post.

> Because openssl-project is readonly for most developers

s/developers/users/

> and I don't think it would be a good idea to join openssl-dev
> and openssl-users.

Well, I've been on both for a long time, and mostly find that
I wish the openssl-dev posts were on openssl-users instead,
they really mostly aren't about ongoing OpenSSL development.

-- 
Viktor.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Steffen Nurpmeso]

Viktor Dukhovni  wrote:
 |> On Jan 24, 2018, at 9:27 AM, Michael Richardson  wrote:
 |>> email clients are designed to handle hundreds to thousands of messages
 |>> a day, Github UI isn't
 |
 |Indeed email is best for informal ad-hoc back and forth threaded
 |discussion, while Github et. al. are for issue tracking.
 |
 |If there's a clear problem that requires tracking and resolution,
 |then the right forum is Github.  If there's a topic to discuss,
 |we have openssl-users.  Most openssl-dev threads were more
 |appropriate for openssl-users.

I see an overwhelming amount of posts on the new list which where
somehow missed on -dev, though.

As a general note that you might not know, from Germany at least
and over my internet account and being not a logged in user i find
that github very often fails to generate commit data or cuts
directory listings.  At least there are no advertisings which
consume multiple CPUs for who-knows-what.

 |So I'm not convinced we need two free-form discussion lists, but
 |concur that if it is discussion one wants, then email clearly
 |superior to Github issue tracking.  The key question is whether
 |openssl-users suffices to meet that need.

Oh, -dev was a terribly noisy list.  So: ch-ch-ch-ch-changes
(turn and face the strange).

Congratulations for the price you have won.  Especially so in
respect to, brave new world!, having to go over browser based
issue tracker interfaces.  I could not do that.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Dr. Matthias St. Pierre]

On 24.01.2018 18:32, Viktor Dukhovni wrote:
>
>> On Jan 24, 2018, at 9:27 AM, Michael Richardson  wrote:
>>
>>> email clients are designed to handle hundreds to thousands of messages
>>> a day, Github UI isn't
> Indeed email is best for informal ad-hoc back and forth threaded
> discussion, while Github et. al. are for issue tracking.
>
> If there's a clear problem that requires tracking and resolution,
> then the right forum is Github.  If there's a topic to discuss,
> we have openssl-users.  Most openssl-dev threads were more
> appropriate for openssl-users.
>
> So I'm not convinced we need two free-form discussion lists, but
> concur that if it is discussion one wants, then email clearly
> superior to Github issue tracking.  The key question is whether
> openssl-users suffices to meet that need.
>

Although GitHub issues provide nice features like markdown and
syntax highlighting, I agree with Viktor that in general mailing lists are
much more suitable for general discussion. If nothing else, then because
they are open for everyone to read and search (via the mail archives)
and don't require a login.

So IMHO GitHub issues should remain for topics like bug reports and
specific discussions related to current pull requests.

As for the two mailing lists openssl-users and openssl-dev: It was always
my understanding that the former was for usability questions starting
from newbie questions up to very sophisticated subjects, whereas
openssl-dev was for discussion around the development process itself.
If we agree that mailing lists are preferrable to GitHub threads, then we
should not close down openssl-dev. Because openssl-project is readonly
for most developers and I don't think it would be a good idea
to join openssl-dev and openssl-users.

Matthias

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Viktor Dukhovni]

> On Jan 24, 2018, at 9:27 AM, Michael Richardson  wrote:
> 
>> email clients are designed to handle hundreds to thousands of messages
>> a day, Github UI isn't

Indeed email is best for informal ad-hoc back and forth threaded
discussion, while Github et. al. are for issue tracking.

If there's a clear problem that requires tracking and resolution,
then the right forum is Github.  If there's a topic to discuss,
we have openssl-users.  Most openssl-dev threads were more
appropriate for openssl-users.

So I'm not convinced we need two free-form discussion lists, but
concur that if it is discussion one wants, then email clearly
superior to Github issue tracking.  The key question is whether
openssl-users suffices to meet that need.

-- 
Viktor.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Salz, Rich via openssl-dev]

  *   OpenSSL should provide API to retrieve extension by OID.

Yes!  Can you open a github issue for that?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Yun Jiang]

Thanks!

But we are providing SDK to our customers to retrieve extension from the 
certificates downloaded from Internet. We have no idea what OID will be used by 
the SDK users. Only SDK users will know what OID will be expected in a 
certificate.

OpenSSL should provide API to retrieve extension by OID.

Yun

From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Salz, 
Rich via openssl-dev
Sent: 24 January 2018 14:40
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

Create the OID at your program startup and store the NID in a global variable.

From: Yun Jiang >
Reply-To: openssl-dev >
Date: Wednesday, January 24, 2018 at 7:38 AM
To: openssl-dev >
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

Thanks!

The problem is that I need to get a customized certificate extension based on 
an OID. Until now, I cannot find a solution without dynamically calling 
OBJ_create(OID, NULL. NULL).


Yun



From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Peter 
Waltenberg
Sent: 24 January 2018 01:23
To: Salz, Rich >; 
openssl-dev@openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

It's also not that much of a problem in practice..
If you are using those API's you are adding new crypto. methods. Doing that 
after threading has started is not going to give good results with or without 
locking.

Peter




From:"Salz, Rich via openssl-dev" 
>
To:"openssl-dev@openssl.org" 
>
Date:24/01/2018 11:19
Subject:Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c
Sent by:"openssl-dev" 
>



  *   OpenSSL APIs, which makes the following OpenSSL documentation statement 
invalid 
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html)


  *   "OpenSSL can safely be used in multi-threaded applications provided that 
at least two callback functions are set, locking_function and threadid_func."


  *   Is there any planning to fix this issue?


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.--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw=


-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Salz, Rich via openssl-dev]

Create the OID at your program startup and store the NID in a global variable.

From: Yun Jiang 
Reply-To: openssl-dev 
Date: Wednesday, January 24, 2018 at 7:38 AM
To: openssl-dev 
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

Thanks!

The problem is that I need to get a customized certificate extension based on 
an OID. Until now, I cannot find a solution without dynamically calling 
OBJ_create(OID, NULL. NULL).


Yun



From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Peter 
Waltenberg
Sent: 24 January 2018 01:23
To: Salz, Rich ; openssl-dev@openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

It's also not that much of a problem in practice..
If you are using those API's you are adding new crypto. methods. Doing that 
after threading has started is not going to give good results with or without 
locking.

Peter




From:"Salz, Rich via openssl-dev" 
>
To:"openssl-dev@openssl.org" 
>
Date:24/01/2018 11:19
Subject:Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c
Sent by:"openssl-dev" 
>



  *   OpenSSL APIs, which makes the following OpenSSL documentation statement 
invalid 
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html)


  *   "OpenSSL can safely be used in multi-threaded applications provided that 
at least two callback functions are set, locking_function and threadid_func."


  *   Is there any planning to fix this issue?


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.--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw=



-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Michael Richardson]

Hubert Kario  wrote:
> that marking a conversation as ignored and going to next one is two key
> combinations and less than a second, github ones require me to go to
> the web UI which is slow, and if I have to view the issue because
> subject is ambiguous it takes ten times as long as it does when using
> email

+1

> email clients are designed to handle hundreds to thousands of messages
> a day, Github UI isn't



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Benjamin Kaduk via openssl-dev]

On 01/23/2018 07:19 PM, Salz, Rich via openssl-dev wrote:
>
>   * OpenSSL APIs, which makes the following OpenSSL documentation
> statement invalid
> (https://www.openssl.org/docs/man1.0.2/crypto/threads.html
> 
> )
>
>  
>
>   * "OpenSSL can safely be used in multi-threaded applications
> provided that at least two callback functions are set,
> locking_function and threadid_func."
>
>  
>
>   * Is there any planning to fix this issue?
>
>  
>
>  
>
> 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.

-Ben
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Yun Jiang]

Thanks!

The problem is that I need to get a customized certificate extension based on 
an OID. Until now, I cannot find a solution without dynamically calling 
OBJ_create(OID, NULL. NULL).


Yun



From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Peter 
Waltenberg
Sent: 24 January 2018 01:23
To: Salz, Rich ; openssl-dev@openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

It's also not that much of a problem in practice..
If you are using those API's you are adding new crypto. methods. Doing that 
after threading has started is not going to give good results with or without 
locking.

Peter




From:"Salz, Rich via openssl-dev" 
>
To:"openssl-dev@openssl.org" 
>
Date:24/01/2018 11:19
Subject:Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c
Sent by:"openssl-dev" 
>



  *   OpenSSL APIs, which makes the following OpenSSL documentation statement 
invalid 
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html)


  *   "OpenSSL can safely be used in multi-threaded applications provided that 
at least two callback functions are set, locking_function and threadid_func."


  *   Is there any planning to fix this issue?


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.--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw=


-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

[Yun Jiang]

Thanks! Is this issue fixed in 1.1.0?

Yun

From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Salz, 
Rich via openssl-dev
Sent: 24 January 2018 01:19
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

Ø  OpenSSL APIs, which makes the following OpenSSL documentation statement 
invalid 
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html)


Ø  "OpenSSL can safely be used in multi-threaded applications provided that at 
least two callback functions are set, locking_function and threadid_func."


Ø  Is there any planning to fix this issue?





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.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev