On 06/15/2015 06:02 PM, Nico Williams wrote:
On Thu, Jun 11, 2015 at 10:41:58AM +0200, Florian Weimer wrote:
Detecting things in libcrypto is very difficult on GNU/Linux due to the
way dynamic linking works.
Details?
Detection based on weak symbols can break due to linking order (if the
On Thu, Jun 11, 2015 at 10:41:58AM +0200, Florian Weimer wrote:
Detecting things in libcrypto is very difficult on GNU/Linux due to the
way dynamic linking works.
Details?
On GNU/Linux, you should try very hard to avoid linking -lpthread and
restrict yourself to the pthreads API subset which
On Mon, Jun 15, 2015 at 06:19:49PM +, Salz, Rich wrote:
My overall goal is that I want to remove the thread callback stuff.
Excellent.
Ideally we have two options: no threads and system-threads.
Presumably that would be either a configure-time option or a run-time
automatic option, but
My overall goal is that I want to remove the thread callback stuff. Ideally we
have two options: no threads and system-threads.
It seems that on Linux shared/static libraries might be an issue. I hope we
can resolve and simplify that.
___
Hmm, another option is to use weak symbols to detect presence of
pthreads. This should work regardless of whether static or dynamic
linking is used.
A statically-linked, single-threaded program that dlopen()s an object
that brings in libpthread will have different OpenSSL dependencies for
the
On 10/30/2013 12:15 AM, Nico Williams wrote:
On Tue, Oct 29, 2013 at 09:58:25PM +0100, Andy Polyakov wrote:
pthreads and Windows, and one can indeed argue why wouldn't OpenSSL
simply default to either of the two when appropriate. While it's
more than appropriate on Windows as it is, on
Not to stand in the way of progress at all, but just to note we
cross-compile OpenSSL libraries for an embedded linux target that is still
using libc_r, not libpthread. That will not change anytime soon for us, at
least on legacy systems.
Besides that, it seems much of this discussion is about
On Oct 31, 2013 8:19 AM, Kevin Fowler kevpfow...@gmail.com wrote:
Not to stand in the way of progress at all, but just to note we
cross-compile OpenSSL libraries for an embedded linux target that is still
using libc_r, not libpthread. That will not change anytime soon for us, at
least on legacy
On Oct 29 21:58, Andy Polyakov wrote:
I feel like saying few words. One should recognize that by the time
multi-threading support was taking shape there was a whole variety
of threading implementations and callbacks were the only way to
convey the specifics. Nowadays we're pretty much talking
On Wed, Oct 30, 2013 at 11:15:27AM +0100, Corinna Vinschen wrote:
Please, before any change is made in terms of threading, let me point
out that Cygwin is NOT Windows, even if it runs on Windows. Cygwin
provides its own pthreads implementation which is always available,
even without explicit
On Oct 30 11:39, Nico Williams wrote:
On Wed, Oct 30, 2013 at 11:15:27AM +0100, Corinna Vinschen wrote:
Please, before any change is made in terms of threading, let me point
out that Cygwin is NOT Windows, even if it runs on Windows. Cygwin
provides its own pthreads implementation which is
On Wed, Oct 30, 2013 at 06:12:08PM +0100, Corinna Vinschen wrote:
Right. I'm just trying to raise awareness before Cygwin gets sorted
into the runs on Windows so use Windows functions drawer, accidentally,
as happened too often in the past in various projects.
I won't.
I'll basically be
On Tue, Oct 29, 2013 at 09:58:25PM +0100, Andy Polyakov wrote:
Another thing: run-time selection from among multiple pthreads
implementations can only safely be managed by the RTLD, and dependencies
on pthreads must still be declared via the linker-editor.
Libraries should be able to refer to
It's getting closer, see:
https://github.com/nicowilliams/openssl/compare/thread_safety
I spoke to a Linux expert and was told that the correct thing to do in
the shared build of OpenSSL is to always link with -lpthread. I assert
that this is also the correct thing to do on Solaris. It's been
I feel like saying few words. One should recognize that by the time
multi-threading support was taking shape there was a whole variety of
threading implementations and callbacks were the only way to convey the
specifics. Nowadays we're pretty much talking only about pthreads and
Windows, and
On Tue, Oct 29, 2013 at 09:58:25PM +0100, Andy Polyakov wrote:
I feel like saying few words. One should recognize that by the time
multi-threading support was taking shape there was a whole variety
of threading implementations and callbacks were the only way to
convey the specifics. Nowadays
I'm making progress slowly (not my main project). I've run into a bit
of a problem: the dynlock callback setting cannot be made thread-safe
due to the setter API's using three functions to set three related
callbacks.
Also, I'm not sure that the dynlocks need a default implementation. It
seems
On Wed, Oct 23, 2013 at 08:32:35AM +1000, Peter Waltenberg wrote:
There is no 'safe' way to do this other than hardwired. Admitted, we have a
fairly ugly stack on which to find that out, multiple independently
developed lumps of code jammed into the same process, quite a few using
On Wed, Oct 23, 2013 at 12:59:53AM -0500, Nico Williams wrote:
On Wed, Oct 23, 2013 at 08:32:35AM +1000, Peter Waltenberg wrote:
There is no 'safe' way to do this other than hardwired. Admitted, we have a
fairly ugly stack on which to find that out, multiple independently
developed lumps of
No, multiple independently developed libraries in the same process space
calling the same crypto. code was the problem.
Multiple thread models can't work if they call common code, agreed
there :).
The problem we hit early on was that as a library the only way we could
ensure the stack above us
On 22 October 2013 06:47, Nico Williams n...@cryptonector.com wrote:
On Monday, October 21, 2013, Salz, Rich wrote:
I like your proposal, but I'd prefer to see an already initialized
error code returned. Or a flag to the (new?) init api that says ignore if
already set
Thanks for your
But I could have a target that has a weak dependency on pthreads and is
safe when the library is present. Ditto Windows (be unsafe pre-vista/2008,
safe in vista/2008 and later, using same OpenSSL DLLs builds). I'd rather
add this variation later, after the meat of this work is done, assuming
On Oct 22, 2013 10:28 AM, Ben Laurie b...@links.org wrote:
On 22 October 2013 06:47, Nico Williams n...@cryptonector.com wrote:
What I need to know:
- should i add new targets to ./Configure? for now I modified the
linux-elf target, but this feels wrong to me.
- what about Windows? I
The simplest fix involves setting the default only once, as wih the
callbacks, but here I feel that's a shaky idea, that I should allow RAND
method changes at any time, in a thread-safe manner -- more work for
me, but less surprising.
There is no 'safe' way to do this other than hardwired.
I like your proposal, but I'd prefer to see an already initialized error code
returned. Or a flag to the (new?) init api that says ignore if already set
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
On Monday, October 21, 2013, Salz, Rich wrote:
I like your proposal, but I'd prefer to see an already initialized error
code returned. Or a flag to the (new?) init api that says ignore if
already set
Thanks for your reply!
I can add an error, but note that the caller can set then get the
26 matches
Mail list logo
