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