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

2020-04-15 Thread Simon McVittie
On Tue, 14 Apr 2020 at 23:44:54 +0200, Sebastian Andrzej Siewior wrote:
> On 2019-01-08 20:17:42 [+], 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.
> > ()
> 
> 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



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

2020-04-14 Thread Sebastian Andrzej Siewior
On 2019-01-08 20:17:42 [+], 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.
> ()

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

> smcv

Sebastian



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

2019-01-08 Thread Kurt Roeckx
On Tue, Jan 08, 2019 at 08:17:42PM +, Simon McVittie wrote:
> Package: openssl
> Version: 1.1.1a-1
> Severity: important
> Control: found -1 1.1.1~~pre3-1
> Control: affects -1 steam
> 
> The openssl.cnf in the openssl package since 1.1.1~~pre3-1 is incompatible
> with libssl < 1.1.0 (I think that's the right cutoff point), either from
> a partial upgrade or bundled with third-party software.
> 
> 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.
[...]
> This affects libssl1.0.0 in the Steam Runtime installed by the non-free
> steam package, and possibly other third-party software bundles.
> ()

We can add a Breaks, but I'm not sure that's actually going to fix
anything for those non-free 3rd party things.


Kurt