Hello,
It is a good idea.
But first, please remove the emacs stuff.
Now, I see that the ENGINE_load_builtin_engines() is already called at
crypto_openssl.c::crypto_init_lib_engine, is there any require to
duplicate this?
There is already "engine" option, available only to polarssl, it can
easily
Hi.
Ah yes, I first made the patch to an older version where some of these
things don't apply, and then forward-ported it.
How about this?
-
Add support for SSL engine loading the private key.
Option 'engine' is used to specify the name of the engine that
will load the private key.
For
Hi,
Why do we need to crypto_init_lib_engine() twice? Can you please take
a look at init_crypto_pre:: init_crypto_pre()?
I also think crypto_init_lib_engine() should not return the engine...
as won't it simpler to use ENGINE_by_id() at
ssl_openssl.c::tls_ctx_load_priv_file()?
Alon.
On Sun, Jun
Yes, almost :)
Won't it better to call ENGINE_init at setup_engine() or at
try_load_engine() instead of at tls_ctx_load_priv_file()? It is just
that tls_ctx_load_priv_file() can be called more than once, while the
init should be called once, right?
Are you sure all works well if engine is not stat
Those questions are why I'd prefer to reuse the already loaded ENGINE
(engine_persist in crypto_openssl), but it didn't appear to be
exported from the crypto backend (crypto_backend.h), which is why my
previous patch added exporting of it (by means of the init function).
All versions of the patch
