[openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni openssl-users at dukhovni.org
Sun Nov 15 21:16:23 UTC 2015


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.


More information about the openssl-dev mailing list