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 t
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 n
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.
___
openssl-de
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 dy
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 wh
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 p
On Oct 31, 2013 8:19 AM, "Kevin Fowler" 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 systems.
>
> Besi
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 nat
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
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 p
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 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 wh
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 explic
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 talki
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. Nowaday
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
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 t
To: openssl-dev@openssl.org,
Date: 24/10/2013 06:44
Subject: Re: Self-initialization of locking/threadid callbacks and
auto-detection of features
Sent by:owner-openssl-...@openssl.org
On Wed, Oct 23, 2013 at 12:59:53AM -0500, Nico Williams wrote:
> On Wed, Oct
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 lu
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
> dlopen()/
3 00:33
Subject: Re: Self-initialization of locking/threadid callbacks and
auto-detection of features
Sent by:owner-openssl-...@openssl.org
On 22 October 2013 06:47, Nico Williams wrote:
On Monday, October 21, 2013, Salz, Rich wrote:
I like your proposal, but I
On Oct 22, 2013 10:28 AM, "Ben Laurie" wrote:
> On 22 October 2013 06:47, Nico Williams 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 either need to have differ
> 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
su
On 22 October 2013 06:47, Nico Williams 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 reply!
>
>
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
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
26 matches
Mail list logo
