Peter Waltenberg wrote:
Document that this can only be done from the top level executable NOT
from
a shared library - and the top level app can switch the lock model if
it
wants. Changing the locking model is something that really can only be
done
by whatever owns main() anyway - it's not
P Kamath wrote:
I don't think you can avoid a dependency on the system threading
library
though, but I don't see why that would be an issue. Many single-
threaded
programs wind up requiring the threading library on many platforms
anyway
as
it may contain functions like 'clock_gettime'
On 03/30/10 09:16 PM, David Schwartz wrote:
Mark Phalan wrote:
In this case, I presume 'pkinit' only supports one threading model
(or one
set of compatible threading models). So it can set the callbacks.
It can set the callbacks but it can't set them in a way which is safe
from races.
It
Mark Phalan wrote:
Imagine the above case happening in one thread while another thread
makes a similar seemingly innocuous call with a similar effect (dlopen
a
library which uses OpenSSL). What should pkinit and the second library
which uses OpenSSL do? If they set callbacks they'll be
On 03/31/10 01:14 PM, David Schwartz wrote:
Mark Phalan wrote:
Imagine the above case happening in one thread while another thread
makes a similar seemingly innocuous call with a similar effect (dlopen
a
library which uses OpenSSL). What should pkinit and the second library
which uses OpenSSL
Mark Phalan wrote:
Because it fixes the race when libraries are correctly checking to see
if the callbacks are already set before setting their own. It's a one
or
two line change to modify the mis-behaving libraries and new libraries
can take advantage of the new locking.
Two questions:
1)
On 03/31/10 01:46 PM, David Schwartz wrote:
Mark Phalan wrote:
Because it fixes the race when libraries are correctly checking to see
if the callbacks are already set before setting their own. It's a one
or
two line change to modify the mis-behaving libraries and new libraries
can take
Subject:RE: libcrypto safe for library use?
Sent
Mark Phalan wrote:
In this case, I presume 'pkinit' only supports one threading model
(or one
set of compatible threading models). So it can set the callbacks.
It can set the callbacks but it can't set them in a way which is safe
from races.
It can set them before it performs any
Mark Phalan wrote:
On 29 Mar 2010, at 20:20, David Schwartz dav...@webmaster.com wrote:
Mark Phalan wrote:
I think this fix is actually a bad one.
I'm still not clear why you think that.
Because it doesn't solve the problem case -- where one library user sets
callbacks that another
David Schwartz wrote:
Mark Phalan wrote:
In this case, I presume 'pkinit' only supports one threading model
(or one
set of compatible threading models). So it can set the callbacks.
It can set the callbacks but it can't set them in a way which is safe
from races.
It can set them before it
Darryl Miles wrote:
David Schwartz wrote:
Mark Phalan wrote:
In this case, I presume 'pkinit' only supports one threading model
(or one
set of compatible threading models). So it can set the callbacks.
It can set the callbacks but it can't set them in a way which is safe
from races.
It
Howard Chu wrote:
Darryl Miles wrote:
Still don't get it. Lets use Linux as an example.
This is actually one of the easiest to solve. Of course the bigger
problem is that solutions here are all platform-dependent, and
maintenance will be a pain.
ELF shared libraries support .init and
Howard Chu wrote:
ELF shared libraries support .init and .fini sections to contain code
that should be executed just after load and just before unload. Assuming
you had a default set of callbacks in the library, it would be simple to
set them here. Likewise any other shared library that
Darryl Miles wrote:
How does each of the 3 threads arbitrate in a thread-safe manner the
initialization of the OpenSSL related libraries. How does any one of
them know it is the first user ?
For existing code, there is no fix. They will set incompatible callbacks and
they will break. I don't
Peter:
On 29/03/10 1:15 AM, Peter Waltenberg wrote:
Sure - it works if you have a simple application, main - OpenSSL
even main -lib doing SSL - OpenSSL still works.
What's giving us grief (and I suspect the person who first raised this
grief) is:
main - lib that needs SSL to do client
On 03/26/10 10:47 PM, David Schwartz wrote:
Mark Phalan wrote:
Unfortunately that's not really practical. To take an example I'm
familiar with - libgss. libgss can end up calling into OpenSSL in the
following way:
libgss - kerberos - pkinit plugin - openssl
It's simply not practical to
On 03/29/10 12:54 AM, Thor Lancelot Simon wrote:
On Mon, Mar 29, 2010 at 08:03:29AM +1000, Peter Waltenberg wrote:
Historically I suspect the reason there were no default callbacks is that a
sizeable proportion of OpenSSL users didn't use threading at all, and the
baggage hauling in the thread
On 03/29/10 07:15 AM, Peter Waltenberg wrote:
The right way to do it is have the app set it up at init time, either
through calling the OpenSSL functions directly or through a module/lib's
'init/setup' API if that's the one 'responsible' for OpenSSL activity in
your application.
Just in case
On 03/29/10 12:03 AM, Peter Waltenberg wrote:
Historically I suspect the reason there were no default callbacks is that a
sizeable proportion of OpenSSL users didn't use threading at all, and the
baggage hauling in the thread libraries imposed was significant.
I don't think that's an issue
it (cf. point 2).
Regards,
Tanguy
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Mark Phalan
Sent: 25 March 2010 1:14 PM
To: openssl-dev@openssl.org
Subject: libcrypto safe for library use?
The threads(3) manpage states
Patrick Patterson wrote:
Peter:
On 29/03/10 1:15 AM, Peter Waltenberg wrote:
Sure - it works if you have a simple application, main - OpenSSL
even main -lib doing SSL - OpenSSL still works.
What's giving us grief (and I suspect the person who first raised this
grief) is:
main - lib that
Mark Phalan wrote:
I'm just suggesting a compile-time option. The application could always
set the locking callbacks back to NULL if it knew what it was doing.
-M
I think this fix is actually a bad one. Will existing libraries continue to
not set the locking callbacks and fail horribly if
On 29 Mar 2010, at 20:20, David Schwartz dav...@webmaster.com wrote:
Mark Phalan wrote:
I'm just suggesting a compile-time option. The application could
always
set the locking callbacks back to NULL if it knew what it was doing.
-M
I think this fix is actually a bad one.
I'm still not
Mark Phalan wrote:
On 29 Mar 2010, at 20:20, David Schwartz dav...@webmaster.com wrote:
Will existing libraries continue to
not set the locking callbacks and fail horribly if the system OpenSSL
isn't
compiled with this flag?
Or will they set sane locking callbacks to be safe
-- making this
Subject:RE: libcrypto safe for library use
On Mon, Mar 29, 2010 at 08:03:29AM +1000, Peter Waltenberg wrote:
Historically I suspect the reason there were no default callbacks is that a
sizeable proportion of OpenSSL users didn't use threading at all, and the
baggage hauling in the thread libraries imposed was significant.
I don't
On Mon, Mar 29, 2010 at 1:18 AM, Ger Hobbelt g...@hobbelt.com wrote:
a) have an extra API function which delivers the references to the
currently installed callbacks (NULL if none are set up), or
b) a kinda signal() style API function set up where the function which is
used to register those
On Mon, Mar 29, 2010 at 12:03 AM, Peter Waltenberg pwal...@au1.ibm.comwrote:
I don't think that's an issue anymore - threading is the common case now.
common case != everybody
But - there's another issue you've all missed. You can have multiple
independently developed libraries in the
On Mon, Mar 29, 2010 at 12:54 AM, Thor Lancelot Simon t...@panix.com wrote:
Maybe for some people. For others, actually doing locked-bus instructions
by default would wreck OpenSSL's performance beyond compare.
Please don't make locking the default.
+1
--
Met vriendelijke groeten / Best
You can't push and pop the callbacks.
The software is running in multiple threads and being used by multiple
independently developed libraries at the same time.
Do you really plan to swap the thread locking mechanism - (which is
protecting you while you swap the locking mechanism around) while
Hrgh. No, you don't init or terminate anything when you're already trying to
execute it from several threads; such init and termination should be done
before and after that.
When a lib (instead of the app itself) is using OpenSSL on its own and that
lib requires a certain approach it is probably
Date: 03/29/2010 11:47 AM
Subject:Re: libcrypto safe for library use
On 03/26/10 04:44 AM, David Schwartz wrote:
Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
That is correct.
This poses a challenge when using OpenSSL in a
Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no safe way to set
On 03/25/10 02:13 PM, Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no
Mark Phalan wrote:
Unfortunately that's not really practical. To take an example I'm
familiar with - libgss. libgss can end up calling into OpenSSL in the
following way:
libgss - kerberos - pkinit plugin - openssl
It's simply not practical to change libkrb5 and libgss and all
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no safe way to set the locking callbacks
Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
That is correct.
This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no
39 matches
Mail list logo
