[openssl-users] Loading engines recursively and crypto engine lock

[Krzysztof Konopko]

On 10 August 2016 at 15:31, Jakob Bohm <jb-openssl at 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.
​

> 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).

Thanks,
Kris​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160810/fbb30303/attachment.html>