Thank you for working on this!
The proposed SRU carries quite a bit of regression risk I think, since
there are many packages both in and out of the archive that may parse
this file under various different circumstances. A regression that leads
to a TLS failure, possibly across multiple packages at once, would be
severe.
I wonder if it's acceptable to just fix nodejs in the archive to be able
to handle this situation, on the basis that software (whether in the
archive or not) needs to be able to be compatible with libssl3 if it
expects to both examine the *system* openssl configuration and be
functional on Ubuntu 22.04? This alternate approach would carry far less
risk, and would avoid the conffile prompt (in cases where users have
changed it). Why wouldn't this be acceptable?
If not, how long must we keep compatibility against libssl1.1 in our
shipped openssl.cnf? What's the deprecation plan?
> either separately packaged (e.g. as an upgrade leftover)
These packages would be broken and not expected to work. Presumably they
depended on libssl1.1 anyway. What would be the consequence of openssl
declaring a Breaks against libssl1.1?
If we do end up proceeding with the approach you've put in the upload
queue, then I think your Test Plan additionally needs:
* to verify that the default provider is indeed still being used by
libssl3 (ie. the wrong configuration doesn't get used by accident)
* a basic smoke test of libssl3 to ensure that we aren't about to break
the normal use of libssl3 for the entire archive
** Changed in: openssl (Ubuntu Jammy)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1979639
Title:
Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail
Status in nodejs package in Ubuntu:
Confirmed
Status in openssl package in Ubuntu:
Fix Released
Status in nodejs source package in Jammy:
Confirmed
Status in openssl source package in Jammy:
Incomplete
Status in nodejs source package in Kinetic:
Confirmed
Status in openssl source package in Kinetic:
Fix Released
Bug description:
[Impact]
While the default configuration works fine for every package that uses the
system libssl3, any software that uses libssl1.1, either separately packaged
(e.g. as an upgrade leftover) or vendored in (as in nodejs in our own archive)
will fail to load the configuration as they don't have any notion of providers.
If the provider section isn't present in the configuration, libssl3
will load the default provider, which means that commenting out the
section won't impact the behavior of standard libssl3 users.
[Test Plan]
On a system with a pristine openssl configuration:
$ sudo apt install nodejs
$ nodejs - <<EOF
var crypto = require('crypto')
const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', {
modulusLength: 2048 });
var sign = crypto.createSign('RSA-SHA256');
sign.update(Buffer.from("hello"));
sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}));
EOF
Without the fix, the nodejs execution will have a non-zero return code and an
uncaught exception with the following line:
Error: error:25066067:DSO support routines:dlfcn_load:could not load the
shared library
With the fix, there shouldn't be any output, and an exit code of 0.
[Where problems could occur]
There could easily be user errors when trying to merge the new
configuration, for instance if they enabled the legacy provider, as
they might comment out the default provider loading section (which is
necessary if any other provider is explicitly loaded).
[Other Info]
Dear SRU team, please do not move this from -proposed to -updates before
the apt phasing fix has reached it first:
https://bugs.launchpad.net/charm-mysql-innodb-cluster/+bug/1979244
[Original report]
~ $ lsb-release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04 LTS
Release: 22.04
Codename: jammy
https://launchpad.net/debian/+source/openssl/3.0.3-7 includes a single
change,
https://sources.debian.org/src/openssl/3.0.3-8/debian/patches/Remove-
the-provider-section.patch/
That patch solves a problem with programs that use OpenSSL v1
(statically or dynamically linked); these still read
/etc/ssl/openssl.cnf, but the v3-specific sections in the sid/jammy
default config may cause a failure.
One example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011051
Another example: a (non-Ubuntu) Node.js v16 (OpenSSL compiled
statically) hits an error in its crypto lib:
~ $ node
Welcome to Node.js v16.15.0.
Type ".help" for more information.
> const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', {
modulusLength: 2048 });
…
> var sign = crypto.createSign('RSA-SHA256')
…
> sign.update(Buffer.from("hello"))
…
> sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
Uncaught:
Error: error:25066067:DSO support routines:dlfcn_load:could not load the
shared library
at Sign.sign (node:internal/crypto/sig:131:29) {
opensslErrorStack: [
'error:0E076071:configuration file routines:module_run:unknown module
name',
'error:0E07506E:configuration file routines:module_load_dso:error loading
dso',
'error:25070067:DSO support routines:DSO_load:could not load the shared
library'
],
library: 'DSO support routines',
function: 'dlfcn_load',
reason: 'could not load the shared library',
code: 'ERR_OSSL_DSO_COULD_NOT_LOAD_THE_SHARED_LIBRARY'
}
Removing the relevant provider section lines (the Debian patch doesn't
apply cleanly, hence the use of sed) fixes it:
~ $ sed -i '/_sect\b/s/^/# /' /etc/ssl/openssl.cnf
~ $ node
Welcome to Node.js v16.15.0.
Type ".help" for more information.
> const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', {
modulusLength: 2048 });
…
> var sign = crypto.createSign('RSA-SHA256')
…
> sign.update(Buffer.from("hello"))
…
> sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
<Buffer c5 e7 ba 01 5a 33 3f 26 43 bb 4e 47 99 49 e4 c7 60 41 be c6 91 63 c6
5d 0a af 78 5c 15 4a 9f 1a e7 24 99 ce 6a f0 05 b5 48 96 4e 59 b8 d5 69 df 3c
bc ... 206 more bytes>
I realize there is no libssl1.1 on jammy, but a statically linked
OpenSSL is not uncommon (Node.js being a very prominent example).
Would it be possible to get this Debian sid change ported to jammy?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1979639/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
