Many thanks for raising this :) I was prepared to argue for this change as (if working as intended) it has basically no impact on our own applications and could help quite a few unsuspecting users, but since you asked for evidence I did a little digging, and was somewhat surprised by what I found. While it is true that there are quite a bit of software out there that embeds older versions of OpenSSL, NodeJS are the outliers in pointing to /etc/ssl as their OPENSSLDIR. In fact, even our own package points to /usr/lib/ssl, with symlinks to /etc for the config file and the certificates.
I erroneously thought that the OpenSSL upstream default was also /etc/ssl, but as it turns out they're using the more sensible /usr/local/ssl as a default. This limits the impact to 1/ third-party packages depending on our old libssl1.1, 2/ our nodejs package 3/ upstream NodeJS builds I'm not particularly keen on doing this SRU just for the sake of 1/, and 2/ can be fixed in that package, but do we want to break things for 3/ ? I don't know much about the JS ecosystem. My first Google result for `installing nodejs on Ubuntu` was pretty quick to point me towards `nvm` to "easily install different versions of Node", and that tool seems to download upstream binaries directly. I'm OK either way, and I've already started working on extending the test case as per your requests. -- 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
