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

[Simon McVittie]

On Tue, 14 Apr 2020 at 23:44:54 +0200, Sebastian Andrzej Siewior wrote:
> 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.

If we weren't in 2019, we definitely are now... but there are things that
could usefully be done (in Debian or upstream) to stop this class of bug
from happening again next time the SONAME gets bumped.

> > 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.

Presumably the configuration file happened to have avoided using any new
functionality/features/syntax that would make the older library unhappy?

I think setting defaults in the shared library itself would be more
robust, and if a configuration file to override that is necessary,
I still think a SONAME-specific configuration file would be more robust
than expecting all past, present and future OpenSSL branches to share one.

> 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?

It works if you know about it, but ISVs that bundle their own copies of
libraries (OpenSSL, etc.) don't always even know how to do RPATHs and
LD_LIBRARY_PATH correctly, so their chance of getting library-specific
things right seems to be pretty much zero. (Thinking here of the number
of third-party games on Steam that bundle their own copy of libstdc++6,
which reliably breaks recent versions of Mesa...)

> > 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.

I think setting the minimum protocol and security level from inside
the shared library would be more robust, particularly since having
libssl installed does not actually guarantee that openssl will also be
installed (a libssl user might be validating against known-good "pinned"
certificates or CAs, rather than the system-wide PKI trust store in
ca-certificates).

> > 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?

I hacked around it in the Steam Runtime's copy of libssl by making it
default to the equivalent of OPENSSL_CONF=/dev/null if the STEAM_RUNTIME
environment variable is set; but that doesn't help anyone with their
own bundled or statically linked libssl.

    smcv