[Pkg-openssl-devel] Bug#918727: Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Sebastian Andrzej Siewior]

On 2019-01-08 20:17:42 [+0000], Simon McVittie wrote:
> It should probably at least have a Breaks on libssl1.0.2, to protect
> partial upgrades from stretch. Some release notes for users of
> third-party software might also be useful. I realise it probably isn't
> feasible to keep openssl.cnf compatible with all past and future versions.

I think that we are a little late for that.

> It would perhaps be a good idea for future OpenSSL branches to
> use a configuration file that's tied to the major version in their SONAME,
> or otherwise parallel-installable? (openssl1.1.0.cnf, etc.)

I don't remember having a problem in Stretch where we had two libs but
one file. However there the environment variable OPENSSL_CONF which can
be set to a specific configuration file. Wouldn't that work if you
bundle a specific library?

…
> Workaround: use OPENSSL_CONF=/dev/null when running software that depends
> on an older libssl.

Right.

> For context, libssl_conf.so never actually existed on disk, and
> isn't really meant to. In OpenSSL's approach to configuration,
> /etc/ssl/openssl.cnf configuration parameters cause loading of
> native-code modules, which can either be built-in to libcrypto or
> libssl, or real files on disk to be dlopen()ed (like the way Python's
> sys module is built-in to the interpreter, but its readline module is
> external). libssl_conf.so in the default library search path (!) is one
> of several names OpenSSL would try for the ssl_conf module - I think
> the reason it appears in the error message is that it's the last one to
> be tried.
> 
> Since 1.1.0 (commit 59b1696c), there is a ssl_conf module built-in to
> libssl. It moved into libcrypto in 1.1.1 (commit d8f031e8).
> 
> In Debian, since 1.1.1 (August 2018, if we don't count experimental),
> /etc/ssl/openssl.cnf has made use of the ssl_conf mechanism to enforce
> TLS1.2 as the minimum protocol, and 112-bit security (level 2) as
> the minimum security level. This file is only installed if the openssl
> package (containing the openssl command-line tool) is installed. However,
> ca-certificates depends on openssl, so in practice basically all users
> will have it.

exactly.

> This affects libssl1.0.0 in the Steam Runtime installed by the non-free
> steam package, and possibly other third-party software bundles.
> (<https://github.com/ValveSoftware/steam-for-linux/issues/6014>)

It appears to be fixed in Steam. Do you see the need any kind of an
action here?

>     smcv

Sebastian