On Sun, Nov 15, 2015 at 09:14:43PM +0100, Richard Levitte wrote:
> openssl-users> If the engine is not automatically loaded, then scripting
> languages
> openssl-users> that provide wrappers around the various algorithms [break],
> as does other
> openssl-users> software that needs the legacy algoriths, but has never needed
> any
> openssl-users> engines and makes no provisions for loading any.
>
> /PATH/TO/openssl.cnf:
>
> openssl_conf = openssl_init
>
> [openssl_init]
> engines = default_engines
>
> [default_engines]
> legacy = legacy
>
> [legacy]
> engine_id = legacy
> init = 1
> default_algorithms = cast, idea, mdc2, md2, rc5, ripemd, seed, whirlpool, ...
There's lots of code that does not read any ".cnf" files. The CONF
interface has not historically been terribly well documented. What
happens if the engine fails to load? Are any environment variables
that determine CONF file locations honoured in setuid/setgid programs
(do we use secure_getenv(3) where available?).
We'd need to provide a migration document and code samples, that
show how to do "CONF" initialization, and of course create the
legacy engine. All this may delay adoption, as distributions will
need patch upstream code to perform such initialization.
Is the pain worth the gain? I'm inclined to think that dropping
TLS ciphersuite code points, and assembly support, is a rather
sensible first step.
--
Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
