Disclaimer. I personally is not as deeply involved in engine design,
e.g. I have no idea exactly why referred engines, eng_padlock and
eng_cryptodev reside in ./crypto/engine, while others in ./engine.
It seems tht when building a shared version of the library, all
the engines in crypto/engine/ get compiled in, but are
unavailable. Those in engines/ get compiled as a shared library
and are available.
The problem seems to be that the Makefile for cryto/engine/ does
not support making shared libraries.
It shouldn't. If an engine is to be built as shared object, then it
should be moved to ./engine.
The engines in it will not
get loaded if the library is build shared.
The code in crypto/engine/eng_all.c: looks something like:
void ENGINE_load_builtin_engines(void)
{
ENGINE_load_dynamic();
#ifndef OPENSSL_NO_STATIC_ENGINE
#ifndef OPENSSL_NO_HW
ENGINE_load_4758cca();
ENGINE_load_aep();
ENGINE_load_atalla();
ENGINE_load_cswift();
ENGINE_load_chil();
ENGINE_load_nuron();
ENGINE_load_sureware();
ENGINE_load_ubsec();
ENGINE_load_padlock();
#endif
ENGINE_load_cryptodev();
ENGINE_load_gmp();
#endif
Most of those engines are in engines/ except for 2 of them:
padlock and cryptodev. They are in crypto/engine/
This means that currently padlock and cryptodev are not working
in a shared version of the library.
For the record. As far as I understand eng_cryptodev is *BSD-specific
and is not expected to work on Linux in either case. I wonder how do
*BSD people solve this?
I see 2 solutions to this:
- Also provide them as shared libraries
- Don't put them into the #ifndef OPENSSL_NO_STATIC_ENGINE
So let's make it a vote.
1. Should there be or not option for built-in engine in shared library
context, or should all engines without exclusion be available as
loadable modules?
My vote is "there should be an option for built-in engines even in
shared context."
2. If consensus is "yes for the option," which engines should be
available as builtins? Popular ones? Small ones? Self-contained ones?
Those addressing specific CPU capabilities directly? Those packager
wishes to favor? Those we decide on per-engine basis?
My vote is "per-engine basis based primarily on self-contained criteria
[i.e. when engine can operate without additional [user-land] component
provided by 3rd party, where 1st and 2nd parties are OS provider and
OpenSSL]." A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
