I'm very much against uploading this fix as an SRU. While it is a shame that we have interop problems with the rest of the world, fixing this in Jammy right now means we *will* break production for anyone that stores Blowfish-encrypted data.
Doing `apt upgrade` on a production server is supposed to be a fairly routine affair, whereas running into the interop issue means someone somewhere did a dist-upgrade, changed some configuration, wrote new code, or installed a new system, all of which are actions where the user *should* expect possible breakage. -- 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/1990216 Title: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of four bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Decryption for Blowfish with OFB and CFB modes fails due to using a key shorter than expected by default. Encryption will also use a key shorter than expected. Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead to decryption issues. [Test plan] On Focal, run the following and copy the output to your clipboard for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do echo "Test with ${cipher}" | openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done tar c pouet.bf-* | xz | base64 -w 60 You can also run this on Lunar or Mantic if you add "-provider legacy -provider default" to the "openssl enc" invocation. On Jammy, run the following and paste your clipboard base64 -d | xz -d | tar x for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}"; done Only "Test with bf-cbc" and "Test with bf-ecb" will be properly decrypted: the other two will result in garbage on screen. Here is the result of the enc + tar + xz + base64 on Focal (works with Lunar/Mantic too but you need to added ): /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7 8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs AoBQAACjzq5WscRn+wIAAAAABFla Here is the same but from Jammy if you want to test encryption on Jammy and decryption on Lunar/Mantic: /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7 8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3 HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N 2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAAAAAABRzyqPdCqX 1AABrQKAUAAABh3ynbHEZ/sCAAAAAARZWg== The contents are expected to be different due to the use of randomness. Don't try to compare the base64 outputs: I'm only using them to ease testing across containers. [Where problems could occur] This patch makes openssl match the documented default (see "man openssl-enc" and search for "Blowfish" for instance) and fixes decryption from an up-to-date Jammy to pretty much everything else, but it also create an issue for data encrypted on Jammy without this patch and Jammy with this patch. There are two possible cases: encrypted data being streamed across this boundary or data at rest being transferred or read later. Streaming is probably not an issue in practice because it's rather the current situation that has been an issue and it's easy to remedy by updating everything (which is relatively few machines since that's only Jammy and not any other OS or distribution). Data at rest is more annoying since updating Jammy will make it impossible to read the data again without updates to other pieces of software. That sounds like a really bad thing and it kind of is but at the same, the benefits are much larger than the issues. Indeed, there is already an incompatibility at the moment between Jammy and everything else and the more time passes by, the more such problematic files can be created. Luckily very few people are using blowfish nowadays and it's not even enabled by default anymore in openssl. Moreover the software update to work around the issue should be a single API call which is documented in the upstream bug report ( https://github.com/openssl/openssl/issues/18359 ). Finally, I have warned the two projects that I am aware are impacted; this is made easier by the fact that they encountered the initial incompatibility. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18359 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Fix-regression-in-default-key-length-for-Blowfish-CF.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Test-the-default-key-length-of-the-Blowfish-ciphers.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === OpenSSL upstream implemented a fix for their issue #18359 "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" https://github.com/openssl/openssl/issues/18359 as of libssl3 3.0.4 (and thus it is included in recent libssl3 versions in Kinetic). Could this fix be backported to libssl3 in Jammy? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1990216/+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
