This is a discussion on Re: Missing engines from crypto/engine when making a shared library - Openssl ; 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 ...
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)
> #ifndef OPENSSL_NO_STATIC_ENGINE
> #ifndef OPENSSL_NO_HW
> 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
My vote is "there should be an option for built-in engines even in
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 Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org