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>
