On 10/08/2016 15:49, Krzysztof Konopko wrote:
On 10 August 2016 at 15:31, Jakob Bohm <jb-open...@wisemo.com <mailto:jb-open...@wisemo.com>>wrote:

    I am not part of the OpenSSL team and have no idea what their
    thinking or suggestions are.


​Thanks for responding!
​


    However the following should be a generic workaround:

    1. Create a third engine3 which loads both engine1 and engine2
      internally (
    ​​
    without going through OpenSSL and its locks).
      So for example engine3->init calls both engine2->init and
      engine1->init.


​I don't understand how engine3 could be initialised ​"
​
without going through OpenSSL and its locks
​" as it's OpenSSL taking the lock whenever initialising _every_ engine. Also when I call `ENGINE_init()` (indirectly, somewhere deep inside engine1), the implementation of
`ENGINE_init()`
​ takes the engine lock. as well which is the source of the problem.
engine3 would call engine1 and engine2 without going through
a call to ENGINE_init(), thus making OpenSSL itself see the
engine1 and engine2 code as part of engine3 (even though
engine3 really just calls the functions in engine1 and
engine2).
​

    2. engine3 would export/provide all the methods from engine1
      and engine2 by forwarding or reexporting the calls.

    3. OpenSSL itself is instructed to use only your engine3
      wrapper.

    4. As a more ambitious project, someone could write a generic
      "engine3" which loads a list of actual engines from a config
      file.

    At the OpenSSL design level, the OpenSSL team might extend the
    OPENSSL_SSL_CLIENT_ENGINE_AUTOvariable to accept a
    colon-separatedlist of engines rather than just a single engine.



​That sounds interesting but engines in general (and specifically in my case) are independent of each other and in different situations I may want to load one but not the other (for example when testing). But I guess that would be a matter of moving the configuration control from where I have it now into whatever mechanism OpenSSL could have (as proposed above).
The idea would be that "engine3" would be a workaround engine
that simulates the (possibly missing) ability to specify
multiple engines via the OPENSSL_SSL_CLIENT_ENGINE_AUTO
variable.  This not-independent engine3 would do nothing but
load other engines, and may or may not be configurable as to
which real engines it loads.  By doing this, engine3 would also
compensate for the fact that many other OpenSSL APIs seem to
allow only a single engine reference as parameter.

With engine3 responsible for initializing engine2 before engine1,
engine1 would no longer contain code to load engine2, making
engine1 more independent from engine2.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to