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
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
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: [
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
>
29/06/2010 02:00 AM
Subject: RE: [openssl.org #2293] OpenSSL dependence on external threading
functions
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
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
> 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
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
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
> >
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
> 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
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
] 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
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
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
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
Subject:Re: [openssl.org #2293] OpenSSL dependence on external threading
functions is a critical design flaw
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
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
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
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
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
23 matches
Mail list logo