Re: [openssl-dev] [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2015-05-04 Thread Florian Weimer
On 09/03/2014 11:50 PM, Rich Salz via RT wrote: > We're going to try to clean up the threads situation post-1.0.2, but closing > this particular ticket. Can you at least change the FAQ to make sure that OpenSSL is *not* thread safe by default? Currently, it claims the opposite. The error reporti

[openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2014-09-03 Thread Rich Salz via RT
We're going to try to clean up the threads situation post-1.0.2, but closing this particular ticket. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Devel

RE: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-28 Thread Rene Hollan
t the openssl devs do not maintain or support them. Of course, that raises issues of quality control, in spite of any disclaimer. -Original Message- From: owner-openssl-...@openssl.org on behalf of David Schwartz Sent: Mon 6/28/2010 6:45 PM To: openssl-dev@openssl.org Subject: RE: [

RE: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-28 Thread David Schwartz
Darryl Miles wrote: > David Schwartz wrote: > > Actually, that wouldn't work. What if you're using a threading > > library that > > permits threads to run in different SMP domains? In that case, the > > atomic > > instructions would only synchronize between threads running in the > > same SMP >

RE: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-28 Thread Peter Waltenberg
29/06/2010 02:00 AM Subject: RE: [openssl.org #2293] OpenSSL dependence on external threading functions

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-28 Thread Darryl Miles
David Schwartz wrote: Actually, that wouldn't work. What if you're using a threading library that permits threads to run in different SMP domains? In that case, the atomic instructions would only synchronize between threads running in the same SMP domain. As I hinted in another post, the less c

RE: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-28 Thread Mark Phalan
On Mon, 2010-06-28 at 07:06 -0700, David Schwartz wrote: > > Guess I replied too quickly... I see why you thought I was spreading > > misinformation. Of course I agree that every library could be modified > > to use atomic instructions available on their CPU to synchronize. Its > > just a lot of mo

RE: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-28 Thread David Schwartz
> Guess I replied too quickly... I see why you thought I was spreading > misinformation. Of course I agree that every library could be modified > to use atomic instructions available on their CPU to synchronize. Its > just a lot of modifications to be made considering the vast amount of > code out

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-28 Thread Mark Phalan
On Mon, 2010-06-28 at 12:25 +0200, Mark Phalan wrote: > On Fri, 2010-06-25 at 21:43 +0100, Darryl Miles wrote: > > Mark Phalan wrote: > > > > > Except setting up locking at library setup time is inherently racy and > > > *cannot* be done safely. The *only* safe place to setup locking > > > callbac

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-28 Thread Mark Phalan
On Fri, 2010-06-25 at 21:43 +0100, Darryl Miles wrote: > Mark Phalan wrote: > > > Except setting up locking at library setup time is inherently racy and > > *cannot* be done safely. The *only* safe place to setup locking > > callbacks is from the application. libraries cannot safely setup the > >

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-25 Thread Darryl Miles
Mark Phalan wrote: Except setting up locking at library setup time is inherently racy and *cannot* be done safely. The *only* safe place to setup locking callbacks is from the application. libraries cannot safely setup the locking callbacks. Just to make it clear why this is a problem imagine tw

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-25 Thread Michael Sweet
> your execution environment. > > > -Original Message- > From: owner-openssl-...@openssl.org on behalf of Mark Phalan > Sent: Fri 6/25/2010 5:20 AM > To: openssl-dev@openssl.org > Cc: msw...@apple.com > Subject: Re: [openssl.org #2293] OpenSSL dependence on

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-25 Thread Michael Sweet
On Jun 24, 2010, at 4:58 PM, Ger Hobbelt via RT wrote: > The only critical bit here is opinion replacing analysis. I won't get into a personal attack. > As you said so yourself, and I quote: "When both an application and a > library ([...]) both initialize and register their own threading functio

RE: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-25 Thread Rene Hollan
] OpenSSL dependence on external threading functions is a critical design flaw On Fri, 2010-06-25 at 01:58 +0200, Ger Hobbelt via RT wrote: > The only critical bit here is opinion replacing analysis. > > As you said so yourself, and I quote: "When both an application and a > lib

RE: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-25 Thread Rene Hollan
not doing the latter. -Original Message----- From: Darryl Miles [mailto:darryl-mailingli...@netbauds.net] Sent: Fri 6/25/2010 3:01 AM To: openssl-dev@openssl.org Cc: Rene Hollan Subject: Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw R

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-25 Thread Mark Phalan
On Fri, 2010-06-25 at 01:58 +0200, Ger Hobbelt via RT wrote: > The only critical bit here is opinion replacing analysis. > > As you said so yourself, and I quote: "When both an application and a > library ([...]) both initialize and register their own threading functions, > bad things happen and t

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-25 Thread Darryl Miles
Rene Hollan wrote: And how, pray tell, should OpenSSL know the threading model the application uses? Unless I'm missing something, it strikes me as perfectly reasonable for OpenSSL to require a "reasonable" threading API to implement SSL data integrity, and for the application to provide an impl

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-24 Thread Peter Waltenberg
Subject:Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-24 Thread Michael Sweet via RT
On Jun 24, 2010, at 4:58 PM, Ger Hobbelt via RT wrote: > The only critical bit here is opinion replacing analysis. I won't get into a personal attack. > As you said so yourself, and I quote: "When both an application and a > library ([...]) both initialize and register their own threading functio

Re: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-24 Thread Ger Hobbelt via RT
The only critical bit here is opinion replacing analysis. As you said so yourself, and I quote: "When both an application and a library ([...]) both initialize and register their own threading functions, bad things happen and the application can crash.") Indeed. Spot on, I'd say. That is /exactly

RE: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-24 Thread Rene Hollan
ementation that wraps the threading model it uses within that API. -Original Message- From: owner-openssl-...@openssl.org on behalf of Michael Sweet via RT Sent: Thu 6/24/2010 1:19 PM Cc: openssl-dev@openssl.org Subject: [openssl.org #2293] OpenSSL dependence on external threading functions

Out of Office AutoReply: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-24 Thread Marko Pohajac via RT
Office AutoReply: [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw Thank you for your message. I am currently out of the office, with no access to e-mail. I will be returning on 28th of June. For SCE matters please contact bojan.lozin

[openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw

2010-06-24 Thread Michael Sweet via RT
An emerging issue with CUPS and other applications that use it has identified a critical design flaw in how OpenSSL supports multithreading. Specifically, a multi-threaded application or library that uses OpenSSL must provide its own threading functions for OpenSSL to use. When both an applica