openssl 3.0.3-7 needs port from sid to jammy

[David Zuelke]

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

[David Zuelke (dzuelke)]

For reference, here is a related Node.js discussion (converted from an issue): https://github.com/nodejs/node/discussions/43184

[Simon Chopin (schopin)]

Hi,

Thanks for this report, I was actually pondering whether or not to drop
this change when merging 3.0.4-1.

IMO this doesn't merit a SRU of its own as there's an easy workaround,
but it definitely should be bundled into the next one. Meanwhile it'll get
included in my upcoming upload to kinetic (today or tomorrow)

[Simon Chopin (schopin)]

Oh, I just realized it actually affects one package in the archive: nodejs. Indeed, due to upstream needing ABI compatibility with libssl1.1 it was decided to use the embedded copy of openssl, see
https://lists.ubuntu.com/archives/ubuntu-devel/2021-October/041643.html and https://launchpad.net/ubuntu/+source/nodejs/12.22.7~dfsg-2ubuntu2

And indeed, my local, packaged copy of nodejs has the exact same behavior as the one described in OP.

[Simon Chopin (schopin)]

There are a couple of issues here.

First, we should indeed patch the /etc openssl config to comment out the problematic section, especially since they are the same as the default.

Furthermore, we should also patch nodejs in Jammy *not to* look into this configuration file, as it'd be surprising for the user to have their nodejs programs fail with obscure errors when touching an unrelated config file, especially in ways that are presumably perfectly fine.

[David Zuelke (dzuelke)]

I am not 100% sure about patching nodejs; using a config file is documented behavior:

- https://nodejs.org/api/cli.html#--openssl-configfile
- https://nodejs.org/api/cli.html#openssl_conffile

So if you do patch it this way, then at least the logic should be to e.g. call OPENSSL_no_config iff the env var OPENSSL_CONF is empty and no --openssl-config is given (in order to allow users to still explicitly pass a config).

[Launchpad Janitor (janitor)]

This bug was fixed in the package openssl - 3.0.4-1ubuntu1

---------------
openssl (3.0.4-1ubuntu1) kinetic; urgency=medium

  * Merge from Debian unstable (LP: #1979639). Remaining changes:
    - Replace duplicate files in the doc directory with symlinks.
    - d/libssl3.postinst: Revert Debian deletion
      + Skip services restart & reboot notification if needrestart is in-use.
      + Bump version check to to 1.1.1.
      + Use a different priority for libssl1.1/restart-services depending
        on whether a desktop, or server dist-upgrade is being performed.
      + Import libraries/restart-without-asking template as used by above.
    - Add support for building with noudeb build profile.
    - Revert "Enable system default config to enforce TLS1.2 as a
      minimum" & "Increase default security level from 1 to 2".
    - Set OPENSSL_TLS_SECURITY_LEVEL=2 as compiled-in minimum security
      level. Change meaning of SECURITY_LEVEL=2 to prohibit TLS versions
      below 1.2 and update documentation. Previous default of 1, can be set
      by calling SSL_CTX_set_security_level(), SSL_set_security_level() or
      using ':@SECLEVEL=1' CipherString value in openssl.cfg.
    - Use perl:native in the autopkgtest for installability on i386.
    - d/p/skip_tls1.1_seclevel3_tests.patch: new Ubuntu-specific patch for the
      testsuite
    - d/p/Set-systemwide-default-settings-for-libssl-users: partially apply it
      on Ubuntu to make it easier for user to change security level
  * Dropped changes, merged upstream:
    - Add some more string comparison fixes
    - d/p/lp1947588.patch: Cherry-picked as our patches make it very easy to
      trigger the underlying bug
    - d/p/lp1978093/*: renew some expiring test certificates
  * d/p/fix-avx512-overflow.patch: Cherry-picked from upstream to fix a 3.0.4
    regression on AVX-512 capable CPUs.

openssl (3.0.4-1) unstable; urgency=medium

  * Import 3.0.3
    - CVE-2022-2068 (The c_rehash script allows command injection)

openssl (3.0.3-8) unstable; urgency=medium

  * Update to openssl-3.0 head.
  * Avoid reusing the init_lock for a different purpose (Closes: #1011339).

openssl (3.0.3-7) unstable; urgency=medium

  * Remove the provider section from the provided openssl.cnf
   (Closes: #1011051).

openssl (3.0.3-6) unstable; urgency=medium

  * Update to openssl-3.0 head which fixes the expired certs in the testsuite.

 -- Simon Chopin <email address hidden> Thu, 23 Jun 2022 12:43:23 +0200