Re: [openssl.org #1736] Enhancement Request: do away with error inchil engine in absence of dynamic locks - Openssl

This is a discussion on Re: [openssl.org #1736] Enhancement Request: do away with error inchil engine in absence of dynamic locks - Openssl ; On Fri, Aug 29, 2008 at 08:45:12AM +0200, Sander Temme via RT wrote: > 2) Have the engine provide its own callbacks that get set in case the > application does not provide (presumably more suitable) alternatives: I think it ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: [openssl.org #1736] Enhancement Request: do away with error inchil engine in absence of dynamic locks

  1. Re: [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks

    On Fri, Aug 29, 2008 at 08:45:12AM +0200, Sander Temme via RT wrote:
    > 2) Have the engine provide its own callbacks that get set in case the
    > application does not provide (presumably more suitable) alternatives:


    I think it would be entirely sensible for OpenSSL to offer a build-time
    configuration option to implement default locking/id callbacks using
    pthread functions like this. It would be necessary also to link
    libcrypto against -lpthread and/or use the -pthread compiler flag, to
    avoid only picking up dummy libc stubs on some platforms.

    That seems far better than requiring every single OpenSSL application to
    implement exactly the same code over and over again- and in fact for
    many to do so incompletely, omitting the dynamic lock support.

    joe


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  2. Re: [openssl.org #1736] Enhancement Request: do away with error inchil engine in absence of dynamic locks

    On Fri, Aug 29, 2008 at 08:45:12AM +0200, Sander Temme via RT wrote:
    > 2) Have the engine provide its own callbacks that get set in case the
    > application does not provide (presumably more suitable) alternatives:


    I think it would be entirely sensible for OpenSSL to offer a build-time
    configuration option to implement default locking/id callbacks using
    pthread functions like this. It would be necessary also to link
    libcrypto against -lpthread and/or use the -pthread compiler flag, to
    avoid only picking up dummy libc stubs on some platforms.

    That seems far better than requiring every single OpenSSL application to
    implement exactly the same code over and over again- and in fact for
    many to do so incompletely, omitting the dynamic lock support.

    joe
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  3. Re: [openssl.org #1736] Enhancement Request: do away with error in chilengine in absence of dynamic locks

    You need to be really careful here. Simply being dependent on pthreads and
    linking to non-threaded code is pure poison on some OS's. (HP/UX variants
    come to mind).

    If you do decide to add a default set of thread callbacks, you'll at least
    need a build configuration to disable it - I'm only guessing, but there are
    probably quite a few users with either custom threading systems, or still
    running unthreaded. That leaves you with the unpleasant possibility of
    needing two versions of OpenSSL on a system, one linked to pthreads, one
    not.

    I suspect that the current situation,i.e. OpenSSL built thread safe, but
    without explicit dependencies on the system pthread library is the best of
    all possible options. Simply avoiding the problem with the one engine
    that's causing problems does seem like the least disruptive option.

    Peter




    From: Sander Temme

    To: rt@openssl.org

    Cc: openssl-dev@openssl.org

    Date: 12/09/2008 01:46

    Subject: Re: [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks







    On Sep 11, 2008, at 7:04 AM, jorton@redhat.com via RT wrote:

    > On Fri, Aug 29, 2008 at 08:45:12AM +0200, Sander Temme via RT wrote:
    >> 2) Have the engine provide its own callbacks that get set in case the
    >> application does not provide (presumably more suitable) alternatives:

    >
    > I think it would be entirely sensible for OpenSSL to offer a build-
    > time
    > configuration option to implement default locking/id callbacks using
    > pthread functions like this. It would be necessary also to link
    > libcrypto against -lpthread and/or use the -pthread compiler flag, to
    > avoid only picking up dummy libc stubs on some platforms.
    >
    > That seems far better than requiring every single OpenSSL
    > application to
    > implement exactly the same code over and over again- and in fact for
    > many to do so incompletely, omitting the dynamic lock support.



    I agree, a fallback implementation would give OpenSSL a more robust
    interface, and prevent some code smell for implementors. Right now it
    seems that the chil plugin is the only place where dynamic locks are
    actually used, but I assume that will change in the future.

    It seems to me that a generally available set of fallback dynamic
    locking callbacks would be of interest to the library at large, not
    just to the chil plugin so I'd suggest putting those routines
    somewhere else, perhaps closer to crypto/cryptlib.c where the global
    function pointers are allocated?

    My direct (and driven by my affiliation) interest is to unbreak the
    breakage of the chil engine in the absence of dynamic locks, and to
    see that backported to 0.9.8. However, putting the fallback
    implementation in may be the kind of deeper surgery you don't want to
    backport... Can we start a two-pronged approach where we apply and
    backport my original openssl_chil_nolocks_donotbreak.patch and then
    look into the fallback routines? The former is entirely localized to
    the chil engine and does not stand in the way of the latter (since
    when that's done the engine will just find the callbacks in place).

    Thanks,

    S.

    --
    sander@temme.net http://www.temme.net/sander/
    PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF




    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread