[Touch-packages] [Bug 2063271] Re: Illegal opcode in libssl
AFAIU there is no issue in the package at the moment so I'll close the report. Thanks for investigating and trying the package reinstallation. (Also, Alex, impressive intuition!) ** Changed in: openssl (Ubuntu) Status: New => Invalid -- 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/2063271 Title: Illegal opcode in libssl Status in openssl package in Ubuntu: Invalid Bug description: Many programs using openssl now fail, typically with messages such as Illegal instruction (core dumped) This seems to be a serious error, since it affects, for example, update-manager. Since this makes it harder to get security updates, I would also consider it a security vulnerability. The issue seems to be that openssl seems to be an attempt to use an illegal opcode. A few sample entries in /var/log/syslog are: Apr 21 19:16:39 einstein kernel: [495465.431588] traps: update-manager[396881] trap invalid opcode ip:740964b8ac6b sp:7409552125b0 error:0 in libssl.so.3[740964b7a000+5b000] Apr 21 19:16:55 einstein kernel: [495482.104658] traps: python3[396949] trap invalid opcode ip:73607be8ac6b sp:736074d8d5b0 error:0 in libssl.so.3[73607be7a000+5b000] Apr 21 19:40:05 einstein kernel: [496871.653271] traps: chrome-gnome-sh[397293] trap invalid opcode ip:79432ffa7c6b sp:7ffd6bc03e70 error:0 in libssl.so.3[79432ff97000+5b000] Apr 22 16:23:08 einstein kernel: [501744.765118] traps: check-new-relea[400397] trap invalid opcode ip:797c7cc8ac6b sp:797c6cace5b0 error:0 in libssl.so.3[797c7cc7a000+5b000] Apr 23 15:08:03 einstein kernel: [518701.050526] traps: wget[443588] trap invalid opcode ip:73a8b2eb4c6b sp:7ffc04918740 error:0 in libssl.so.3[73a8b2ea4000+5b000] Apr 23 15:12:55 einstein kernel: [518992.493020] traps: curl[443851] trap invalid opcode ip:7e4e3951dc6b sp:7ffc804d2ed0 error:0 in libssl.so.3[7e4e3950d000+5b000] Apr 23 15:13:32 einstein kernel: [519029.181422] traps: apport-gtk[04] trap invalid opcode ip:7039180f5c6b sp:703902bfaad0 error:0 in libssl.so.3[7039180e5000+5b000] This bug report itself had to be submitted manually since ubuntu-bug now itself fails. lsb_release -rd reports: Description:Ubuntu 22.04.4 LTS Release:22.04 apt-cache policy openssl reports: openssl: Installed: 3.0.2-0ubuntu1.15 Candidate: 3.0.2-0ubuntu1.15 Version table: *** 3.0.2-0ubuntu1.15 500 500 http://us.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 100 /var/lib/dpkg/status 3.0.2-0ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages /proc/version for my computer gives Linux version 6.5.0-28-generic (buildd@lcy02-amd64-098) (x86_64-linux-gnu-gcc-12 (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #29~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr 4 14:39:20 UTC 2 /proc/cpuinfo for my computer starts processor : 0 vendor_id : GenuineIntel cpu family: 6 model : 78 model name: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz stepping : 3 microcode : 0xf0 cpu MHz : 500.018 cache size: 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid: 0 initial apicid: 0 fpu : yes fpu_exception : yes cpuid level : 22 wp: yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_stale_data retbleed gds bogomips : 5199.98 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2063271/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1297025] Re: Either the changelog.gz is missing or there is an erroneous link in the libssl1.0.0 package
** Changed in: openssl (Ubuntu) Milestone: None => ubuntu-24.10 -- 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/1297025 Title: Either the changelog.gz is missing or there is an erroneous link in the libssl1.0.0 package Status in openssl package in Ubuntu: In Progress Bug description: In libssl-dev for both Precise and Saucy packages for libssl-dev, there is a broken link: # ls -l /usr/share/doc/libssl-dev/changelog.gz lrwxrwxrwx 1 root root 27 Jan 8 12:48 /usr/share/doc/libssl-dev/changelog.gz -> ../libssl1.0.0/changelog.gz # ls -l /usr/share/doc/libssl1.0.0/changelog.gz ls: cannot access /usr/share/doc/libssl1.0.0/changelog.gz: No such file or directory I have verified this in both releases while trying to debug a failing build of a 3rd party library that links against these. Build works in Precise, fails in Saucy. Was looking to see what changed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1297025/+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
[Touch-packages] [Bug 1297025] Re: Either the changelog.gz is missing or there is an erroneous link in the libssl1.0.0 package
I plan to work on this during the OO cycle. It's an issue inherited from Debian AFAIU. -- 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/1297025 Title: Either the changelog.gz is missing or there is an erroneous link in the libssl1.0.0 package Status in openssl package in Ubuntu: In Progress Bug description: In libssl-dev for both Precise and Saucy packages for libssl-dev, there is a broken link: # ls -l /usr/share/doc/libssl-dev/changelog.gz lrwxrwxrwx 1 root root 27 Jan 8 12:48 /usr/share/doc/libssl-dev/changelog.gz -> ../libssl1.0.0/changelog.gz # ls -l /usr/share/doc/libssl1.0.0/changelog.gz ls: cannot access /usr/share/doc/libssl1.0.0/changelog.gz: No such file or directory I have verified this in both releases while trying to debug a failing build of a 3rd party library that links against these. Build works in Precise, fails in Saucy. Was looking to see what changed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1297025/+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
[Touch-packages] [Bug 2063898] Re: broken doc symlinks after t64 transition in noble
*** This bug is a duplicate of bug 1297025 *** https://bugs.launchpad.net/bugs/1297025 ** This bug has been marked a duplicate of bug 1297025 Either the changelog.gz is missing or there is an erroneous link in the libssl1.0.0 package -- 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/2063898 Title: broken doc symlinks after t64 transition in noble Status in openssl package in Ubuntu: Confirmed Bug description: $ pwd /usr/share/doc/openssl $ ls -l total 52 lrwxrwxrwx 1 root root30 mars 31 08:42 changelog.Debian.gz -> ../libssl3/changelog.Debian.gz lrwxrwxrwx 1 root root23 mars 31 08:42 changelog.gz -> ../libssl3/changelog.gz lrwxrwxrwx 1 root root20 mars 31 08:42 copyright -> ../libssl3/copyright libssl3 doenst exist anymore, it is now libssl3t64 $ apt-cache policy openssl libssl3t64 openssl: Installed: 3.0.13-0ubuntu3 Candidate: 3.0.13-0ubuntu3 Version table: *** 3.0.13-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages 100 /var/lib/dpkg/status libssl3t64: Installed: 3.0.13-0ubuntu3 Candidate: 3.0.13-0ubuntu3 Version table: *** 3.0.13-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2063898/+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
[Touch-packages] [Bug 2062167] Re: [FFe] openssl: post-3.0.13 changes from git
** Changed in: openssl (Ubuntu) Status: Triaged => New -- 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/2062167 Title: [FFe] openssl: post-3.0.13 changes from git Status in openssl package in Ubuntu: New Bug description: I would like to have the most recent openssl version possible in Noble. For that I am requesting to upload all the commits in the openssl-3.0 branch that follow 3.0.13 which is already in the archive. I would like to include 3.0.14 afterwards if feasible. Having the most recent commits of the 3.0 branch will make that easier. I went through all commits since 3.0.13 at the end of January. I skipped a few which touch files that are not in the 3.0.13 release tarball (github CI stuff mostly) and edited one that touched such a file. There are only fixes. This is not surprising considering we are past the 13th patch release for openssl 3.0, and almost 3 years after 3.0 was released. Changes are most usually backports which is a good thing as it means they are also tested in the other branches, including through 3.3, for which the .0 release was published a few days ago after weeks in beta/RC. There are a few behaviour tweaks, and that is why I want to get as close as possible to what 3.0.14 will be. The bigger one is ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6: Revert "Improved detection of engine-provided private "classic" keys", which also states "The workaround has caused more problems than it solved." As I said, I went through all commits. All look safe to me. The question really boils down to whether we will include these fixes in Noble now or if we won't: there is only a very very small chance that any given change is SRU'ed afterwards. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2062167/+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
[Touch-packages] [Bug 2062167] Re: [FFe] openssl: post-3.0.13 changes from git
Note that there is a CVE fix in there too. It's low-severity because it's only unbounded memory growth but it's quite easy to trigger and I think that anyone who has a webserver with TLS 1.3 will want it patched. Therefore there should be an upload of this at least. -- 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/2062167 Title: [FFe] openssl: post-3.0.13 changes from git Status in openssl package in Ubuntu: Triaged Bug description: I would like to have the most recent openssl version possible in Noble. For that I am requesting to upload all the commits in the openssl-3.0 branch that follow 3.0.13 which is already in the archive. I would like to include 3.0.14 afterwards if feasible. Having the most recent commits of the 3.0 branch will make that easier. I went through all commits since 3.0.13 at the end of January. I skipped a few which touch files that are not in the 3.0.13 release tarball (github CI stuff mostly) and edited one that touched such a file. There are only fixes. This is not surprising considering we are past the 13th patch release for openssl 3.0, and almost 3 years after 3.0 was released. Changes are most usually backports which is a good thing as it means they are also tested in the other branches, including through 3.3, for which the .0 release was published a few days ago after weeks in beta/RC. There are a few behaviour tweaks, and that is why I want to get as close as possible to what 3.0.14 will be. The bigger one is ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6: Revert "Improved detection of engine-provided private "classic" keys", which also states "The workaround has caused more problems than it solved." As I said, I went through all commits. All look safe to me. The question really boils down to whether we will include these fixes in Noble now or if we won't: there is only a very very small chance that any given change is SRU'ed afterwards. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2062167/+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
[Touch-packages] [Bug 2062167] [NEW] [FFe] openssl: post-3.0.13 changes from git
Public bug reported: I would like to have the most recent openssl version possible in Noble. For that I am requesting to upload all the commits in the openssl-3.0 branch that follow 3.0.13 which is already in the archive. I would like to include 3.0.14 afterwards if feasible. Having the most recent commits of the 3.0 branch will make that easier. I went through all commits since 3.0.13 at the end of January. I skipped a few which touch files that are not in the 3.0.13 release tarball (github CI stuff mostly) and edited one that touched such a file. There are only fixes. This is not surprising considering we are past the 13th patch release for openssl 3.0, and almost 3 years after 3.0 was released. Changes are most usually backports which is a good thing as it means they are also tested in the other branches, including through 3.3, for which the .0 release was published a few days ago after weeks in beta/RC. There are a few behaviour tweaks, and that is why I want to get as close as possible to what 3.0.14 will be. The bigger one is ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6: Revert "Improved detection of engine-provided private "classic" keys", which also states "The workaround has caused more problems than it solved." As I said, I went through all commits. All look safe to me. The question really boils down to whether we will include these fixes in Noble now or if we won't: there is only a very very small chance that any given change is SRU'ed afterwards. ** Affects: openssl (Ubuntu) Importance: High Status: Triaged -- 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/2062167 Title: [FFe] openssl: post-3.0.13 changes from git Status in openssl package in Ubuntu: Triaged Bug description: I would like to have the most recent openssl version possible in Noble. For that I am requesting to upload all the commits in the openssl-3.0 branch that follow 3.0.13 which is already in the archive. I would like to include 3.0.14 afterwards if feasible. Having the most recent commits of the 3.0 branch will make that easier. I went through all commits since 3.0.13 at the end of January. I skipped a few which touch files that are not in the 3.0.13 release tarball (github CI stuff mostly) and edited one that touched such a file. There are only fixes. This is not surprising considering we are past the 13th patch release for openssl 3.0, and almost 3 years after 3.0 was released. Changes are most usually backports which is a good thing as it means they are also tested in the other branches, including through 3.3, for which the .0 release was published a few days ago after weeks in beta/RC. There are a few behaviour tweaks, and that is why I want to get as close as possible to what 3.0.14 will be. The bigger one is ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6: Revert "Improved detection of engine-provided private "classic" keys", which also states "The workaround has caused more problems than it solved." As I said, I went through all commits. All look safe to me. The question really boils down to whether we will include these fixes in Noble now or if we won't: there is only a very very small chance that any given change is SRU'ed afterwards. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2062167/+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
[Touch-packages] [Bug 2009544] Re: OpenSSL 3 performance regression
** Also affects: openssl (Ubuntu Noble) Importance: Undecided Status: Confirmed ** Also affects: openssl (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Mantic) Importance: Undecided Status: New ** Changed in: openssl (Ubuntu Mantic) Status: New => Won't Fix ** Changed in: openssl (Ubuntu Jammy) Status: New => Confirmed -- 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/2009544 Title: OpenSSL 3 performance regression Status in openssl package in Ubuntu: Confirmed Status in openssl source package in Jammy: Confirmed Status in openssl source package in Mantic: Won't Fix Status in openssl source package in Noble: Confirmed Bug description: Hello, it sounds like there's some significant performance regressions in OpenSSL 3: https://github.com/openssl/openssl/issues/20286#issuecomment-1438826816 Some we might be able to address with: https://github.com/openssl/openssl/pull/18151 Some of the performance differences may be subject to ongoing work. Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+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
[Touch-packages] [Bug 2009544] Re: OpenSSL 3 performance regression
I'm going to target this to 24.10 as it's the first time it will be possible to "solve" it. As far as I understand, there will probably be performance loss with 3.3 compared to 1.1 but it's going to be a long tail rather than a few big changes which have been included in 3.1, 3.2 and 3.3. Btw, Antoine, are you able to test with 3.3 beta? I'd like to know where we'll stand and if we should take additional steps. I'm also not opposed to performance backports for 22.04 but I must make it clear that these take time to author, test and validate, and also require calendar time (at which point the next release might very well be out). -- 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/2009544 Title: OpenSSL 3 performance regression Status in openssl package in Ubuntu: Confirmed Bug description: Hello, it sounds like there's some significant performance regressions in OpenSSL 3: https://github.com/openssl/openssl/issues/20286#issuecomment-1438826816 Some we might be able to address with: https://github.com/openssl/openssl/pull/18151 Some of the performance differences may be subject to ongoing work. Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+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
[Touch-packages] [Bug 2009544] Re: OpenSSL 3 performance regression
Due to openssl's release schedule, 24.04 Noble Numbat will still use 3.0. It will be 3.0.13 unless a 3.0.14 is released very soon. After Noble Numbat is released, I will work on openssl 3.3 for the subsequent Ubuntu release. It is not yet released but will be soon so I might start with beta/RC. The openssl release schedule dictates that there will be another openssl LTS release by the time Ubuntu's next release (26.04) enters development. Unfortunately there is little way around this due to openssl's own schedule and the need to have very long support. -- 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/2009544 Title: OpenSSL 3 performance regression Status in openssl package in Ubuntu: Confirmed Bug description: Hello, it sounds like there's some significant performance regressions in OpenSSL 3: https://github.com/openssl/openssl/issues/20286#issuecomment-1438826816 Some we might be able to address with: https://github.com/openssl/openssl/pull/18151 Some of the performance differences may be subject to ongoing work. Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+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
[Touch-packages] [Bug 2059417] Re: Sync xz-utils 5.6.1-1 (main) from Debian unstable (main)
** Description changed: + NOTE: THIS IS AN ATTEMPT AT INCLUDING A BACKDOOR. THIS IS LEFT FOR + HISTORICAL PURPOSES ONLY AND MUST NOT BE DONE. + + Please sync xz-utils 5.6.1-1 (main) from Debian unstable (main) Hello! I am one of the upstream maintainers for XZ Utils. Version 5.6.1 was recently released and uploaded to Debian as a bugfix only release. Notably, this fixes a bug that causes Valgrind to issue a warning on any application dynamically linked with liblzma. This includes a lot of important applications. This could break build scripts and test pipelines that expect specific output from Valgrind in order to pass. Additionally, this fixes a small typo for the man pages translations for Brazilian Portuguese, German, French, Korean, Romanian, and Ukrainian, and removes the need for patches applied for version 5.6.0-0.2. The other bugfixes in this release have no impact on Ubuntu. They involve building with CMake or when building on a system without Landlock system calls defined (these are defined in Ubuntu). Changelog entries since current noble version 5.6.0-0.2: xz-utils (5.6.1-1) unstable; urgency=medium * Non-maintainer upload. * Import 5.6.1 (Closes: #1067708). * Takeover maintenance of the package. -- Sebastian Andrzej Siewior Wed, 27 Mar 2024 22:53:21 +0100 - Excerpt from the NEWS entry from upstream: 5.6.1 (2024-03-09) - * liblzma: Fixed two bugs relating to GNU indirect function (IFUNC) - with GCC. The more serious bug caused a program linked with - liblzma to crash on start up if the flag -fprofile-generate was - used to build liblzma. The second bug caused liblzma to falsely - report an invalid write to Valgrind when loading liblzma. + * liblzma: Fixed two bugs relating to GNU indirect function (IFUNC) + with GCC. The more serious bug caused a program linked with + liblzma to crash on start up if the flag -fprofile-generate was + used to build liblzma. The second bug caused liblzma to falsely + report an invalid write to Valgrind when loading liblzma. - * xz: Changed the messages for thread reduction due to memory - constraints to only appear under the highest verbosity level. + * xz: Changed the messages for thread reduction due to memory + constraints to only appear under the highest verbosity level. - * Build: + * Build: - - Fixed a build issue when the header file - was present on the system but the Landlock system calls were - not defined in . + - Fixed a build issue when the header file + was present on the system but the Landlock system calls were + not defined in . - - The CMake build now warns and disables NLS if both gettext - tools and pre-created .gmo files are missing. Previously, - this caused the CMake build to fail. + - The CMake build now warns and disables NLS if both gettext + tools and pre-created .gmo files are missing. Previously, + this caused the CMake build to fail. - * Minor improvements to man pages. + * Minor improvements to man pages. - * Minor improvements to tests. + * Minor improvements to tests. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xz-utils in Ubuntu. https://bugs.launchpad.net/bugs/2059417 Title: Sync xz-utils 5.6.1-1 (main) from Debian unstable (main) Status in xz-utils package in Ubuntu: Won't Fix Bug description: NOTE: THIS IS AN ATTEMPT AT INCLUDING A BACKDOOR. THIS IS LEFT FOR HISTORICAL PURPOSES ONLY AND MUST NOT BE DONE. Please sync xz-utils 5.6.1-1 (main) from Debian unstable (main) Hello! I am one of the upstream maintainers for XZ Utils. Version 5.6.1 was recently released and uploaded to Debian as a bugfix only release. Notably, this fixes a bug that causes Valgrind to issue a warning on any application dynamically linked with liblzma. This includes a lot of important applications. This could break build scripts and test pipelines that expect specific output from Valgrind in order to pass. Additionally, this fixes a small typo for the man pages translations for Brazilian Portuguese, German, French, Korean, Romanian, and Ukrainian, and removes the need for patches applied for version 5.6.0-0.2. The other bugfixes in this release have no impact on Ubuntu. They involve building with CMake or when building on a system without Landlock system calls defined (these are defined in Ubuntu). Changelog entries since current noble version 5.6.0-0.2: xz-utils (5.6.1-1) unstable; urgency=medium * Non-maintainer upload. * Import 5.6.1 (Closes: #1067708). * Takeover maintenance of the package. -- Sebastian Andrzej Siewior Wed, 27 Mar 2024 22:53:21 +0100 Excerpt from the NEWS entry from
[Touch-packages] [Bug 2055422] Re: Please sync xz-utils 5.6.0-0.2 from Debian experimental
I had forgotten about this bug. Thanks for bringing this up and let me close this. ** Changed in: xz-utils (Ubuntu) Status: New => Invalid ** Description changed: + NOTE: THE VERSION MENTIONED HERE HAS BEEN BACKDOORED. + I am keeping the text below unchanged due to its possible historical relevance. + + == + Xz-utils 5.6.0 was released last Friday. It features a much faster decompression code on all platforms but on x86_64 in particular, it is 60% faster in my testing. It also aligns better current practices of enabling multi-threading by default (always with a default memory limit of 25% of the system physical memory). Sebastian Andrzej Siewior has uploaded it to experimental and after a few fixes for integration (due to extra output on stderr in particular), has uploaded xz-utils 5.6.0-0.2. I expect tests to pass now considering they almost all succeeded with the first upload. I am aware of tweaks to other packages too but I'm not sure they will actually be needed with this new upload and since they relate to pristine-tar and/or dpkg, I think it's probably better to be sure first due to the ongoing migrations. Thanks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xz-utils in Ubuntu. https://bugs.launchpad.net/bugs/2055422 Title: Please sync xz-utils 5.6.0-0.2 from Debian experimental Status in xz-utils package in Ubuntu: Invalid Bug description: NOTE: THE VERSION MENTIONED HERE HAS BEEN BACKDOORED. I am keeping the text below unchanged due to its possible historical relevance. == Xz-utils 5.6.0 was released last Friday. It features a much faster decompression code on all platforms but on x86_64 in particular, it is 60% faster in my testing. It also aligns better current practices of enabling multi-threading by default (always with a default memory limit of 25% of the system physical memory). Sebastian Andrzej Siewior has uploaded it to experimental and after a few fixes for integration (due to extra output on stderr in particular), has uploaded xz-utils 5.6.0-0.2. I expect tests to pass now considering they almost all succeeded with the first upload. I am aware of tweaks to other packages too but I'm not sure they will actually be needed with this new upload and since they relate to pristine-tar and/or dpkg, I think it's probably better to be sure first due to the ongoing migrations. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2055422/+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
[Touch-packages] [Bug 2059417] Re: Sync xz-utils 5.6.1-1 (main) from Debian unstable (main)
I'll dive deeper into this. The timing collides with the t64 transition so that makes me curious. Moreover, Debian reverted to 5.4.5 so the situation where we're on 5.6.0 doesn't match Debian either. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xz-utils in Ubuntu. https://bugs.launchpad.net/bugs/2059417 Title: Sync xz-utils 5.6.1-1 (main) from Debian unstable (main) Status in xz-utils package in Ubuntu: Won't Fix Bug description: Please sync xz-utils 5.6.1-1 (main) from Debian unstable (main) Hello! I am one of the upstream maintainers for XZ Utils. Version 5.6.1 was recently released and uploaded to Debian as a bugfix only release. Notably, this fixes a bug that causes Valgrind to issue a warning on any application dynamically linked with liblzma. This includes a lot of important applications. This could break build scripts and test pipelines that expect specific output from Valgrind in order to pass. Additionally, this fixes a small typo for the man pages translations for Brazilian Portuguese, German, French, Korean, Romanian, and Ukrainian, and removes the need for patches applied for version 5.6.0-0.2. The other bugfixes in this release have no impact on Ubuntu. They involve building with CMake or when building on a system without Landlock system calls defined (these are defined in Ubuntu). Changelog entries since current noble version 5.6.0-0.2: xz-utils (5.6.1-1) unstable; urgency=medium * Non-maintainer upload. * Import 5.6.1 (Closes: #1067708). * Takeover maintenance of the package. -- Sebastian Andrzej Siewior Wed, 27 Mar 2024 22:53:21 +0100 Excerpt from the NEWS entry from upstream: 5.6.1 (2024-03-09) * liblzma: Fixed two bugs relating to GNU indirect function (IFUNC) with GCC. The more serious bug caused a program linked with liblzma to crash on start up if the flag -fprofile-generate was used to build liblzma. The second bug caused liblzma to falsely report an invalid write to Valgrind when loading liblzma. * xz: Changed the messages for thread reduction due to memory constraints to only appear under the highest verbosity level. * Build: - Fixed a build issue when the header file was present on the system but the Landlock system calls were not defined in . - The CMake build now warns and disables NLS if both gettext tools and pre-created .gmo files are missing. Previously, this caused the CMake build to fail. * Minor improvements to man pages. * Minor improvements to tests. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2059417/+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
[Touch-packages] [Bug 2056593] Re: [FFE] FIPS compatibility patches
** Changed in: openssl (Ubuntu) Status: Triaged => Fix Committed -- 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/2056593 Title: [FFE] FIPS compatibility patches Status in openssl package in Ubuntu: Fix Committed Bug description: We have an open MR with a handful of FIPS compatibilty changes we wore hoping to get into 24.04. The main purpose of the changes is to detect whether the kernel is running in FIPS mode and adjust the behavior of the library accordingly by loading the correct provider backend and using defaults that are FIPS compliant (no md5, DES etc) instead trying to use non-compliant code paths and crashing. The proposed patches were taken from the OpenSSL version shipped in the FIPS archive at esm.ubuntu.com for 22.04. Having them in the regular archive will reduce the maintenance work significantly. None of the changes should have any impact on running OpenSSL in regular (non-fips) mode. Below is a detailed list of the changes: - d/p/fips/crypto-Add-kernel-FIPS-mode-detection.patch: This adds a new internal API to determine whether the kernel has been booted in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify an alternative path for the fips_enabled file and is used in tests. The FIPS_MODULE switch can be used to enable build of the the FIPS provider module specific parts which are not needed in the OpenSSL library itself. - d/p/fips/crypto-Automatically-use-the-FIPS-provider-when-the-kerne.patch: This automatically configures all library contexts to use the FIPS provider when the kernel is booted in FIPS mode by: - Setting "fips=yes" as the default property for algorithm fetches - Loading and activating the FIPS provider as the fallback provider. If applications load providers via a configuration either because the default configuration is modified or they override the default configuration, this disables loading of the fallback providers. In this case, the configuration must load the FIPS provider when FIPS mode is enabled, else algorithm fetches will fail Applications can choose to use non-FIPS approved algorithms by specifying the "-fips" or "fips=no" property for algorithm fetches and loading the default provider. - d/p/fips/apps-speed-Omit-unavailable-algorithms-in-FIPS-mode.patch: Omit unavailable algorithms in FIPS mode - d/p/fips/apps-pass-propquery-arg-to-the-libctx-DRBG-fetches.patch The -propquery argument might be used to define a preference for which provider an algorithm is fetched from. Set the query properties for the library context DRBG fetches as well so that they are fetched with the same properties. - d/p/fips/test-Ensure-encoding-runs-with-the-correct-context-during.patch: This test uses 2 library contexts - one context for creating initial test keys, and then another context (or the default context) for running tests. There is an issue that during the encoding tests, the OSSL_ENCODER_CTX is created from the created EVP_PKEYs, which are associated with the library context used to create the keys. This means that encoding tests run with the wrong library context, which always uses the default provider. These changes are now included in a larger MR with other changes in the same package version: https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+merge/462486 The now-superseded MR is at https://code.launchpad.net/~tobhe/ubuntu/+source/openssl/+git/openssl/+merge/460953 Since OpenSSL just received another big update to 3.0.13 we had to rebase our changes and will have to rerun our install/upgrade tests. A test build is also available at https://launchpad.net/~tobhe/+archive/ubuntu/openssl-test/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2056593/+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
[Touch-packages] [Bug 2058017] Re: openssl is not LTO-safe
** Changed in: openssl (Ubuntu) Status: In Progress => Fix Committed -- 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/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: Fix Committed Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. I ran "openssl speed" with a long benchmark time in order to get good results (there is a variation of several percents with the default times). I then scripted a diff which output is shown below; "." means the difference is within 2% which is the vast majority. Also note that some important ciphers are not present due to how openssl speed works; small aes-*-cbc are negatively impacted, up to -10% but that would -50% if you compared between "software" and "hardware" implementations, the results would be reversed at anything but the smallest data sizes, and the fact that you want to use hardware implementations as much as possible means that you also want to avoid places where LTO could have an effect. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes md5 . . . . .. sha1 . . . . .. rmd160. . . . .. sha256+2.3% . . . .. sha512. . . . .. hmac(md5) . . . . .. des-ede3 . . . . .. aes-128-cbc -10.0% . . . .. aes-192-cbc -7.6% . . . .. aes-256-cbc -5.2% . . . .. camellia-128-cbc . . . . .. camellia-192-cbc . . . . .. camellia-256-cbc . . . . .. ghash . . +21.2% -27.3% +30.5% +39.3% rand -2.8% -2.9% -2.9% -2.8% .. sign verify sign/s verify/s rsa 512 bits0.31s
[Touch-packages] [Bug 2058017] Re: openssl is not LTO-safe
** Description changed: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. I ran "openssl speed" with a long benchmark time in order to get good results (there is a variation of several percents with the default - times). I then scripted a diff which output is shown below (hopefully it - will display fine...); entries within 2% are not displayed. Also note + times). I then scripted a diff which output is shown below; "." + means the difference is within 2% which is the vast majority. Also note that some important ciphers are not present due to how openssl speed works; small aes-*-cbc are negatively impacted, up to -10% but that would -50% if you compared between "software" and "hardware" implementations, the results would be reversed at anything but the smallest data sizes, and the fact that you want to use hardware implementations as much as possible means that you also want to avoid places where LTO could have an effect. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes md5 . . . . .. sha1 . . . . .. rmd160. . . . .. sha256+2.3% . . . .. sha512. . . . .. hmac(md5) . . . . .. des-ede3 . . . . .. aes-128-cbc -10.0% . . . .. aes-192-cbc -7.6% . . . .. aes-256-cbc -5.2% . . . .. camellia-128-cbc . . . . .. camellia-192-cbc . . . . .. camellia-256-cbc . . . . .. ghash . . +21.2% -27.3% +30.5% +39.3% rand -2.8% -2.9% -2.9% -2.8% .. sign verify sign/s verify/s rsa 512 bits0.31s 0.02s -2.7%. rsa 1024bits. 0.05s .. rsa 2048bits+2.4%
[Touch-packages] [Bug 2058017] Re: openssl is not LTO-safe
** Description changed: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. - I will add results of "openssl speed" soon (in a few hours). + I ran "openssl speed" with a long benchmark time in order to get good + results (there is a variation of several percents with the default + times). I then scripted a diff which output is shown below (hopefully it + will display fine...); entries within 2% are not displayed. Also note + that some important ciphers are not present due to how openssl speed + works; small aes-*-cbc are negatively impacted, up to -10% but that + would -50% if you compared between "software" and "hardware" + implementations, the results would be reversed at anything but the + smallest data sizes, and the fact that you want to use hardware + implementations as much as possible means that you also want to avoid + places where LTO could have an effect. + + type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes + md5 + sha1 + rmd160 + sha256+2.3% + sha512 + hmac(md5) + des-ede3 + aes-128-cbc -10.0% + aes-192-cbc -7.6% + aes-256-cbc -5.2% + camellia-128-cbc + camellia-192-cbc + camellia-256-cbc + ghash +21.2% -27.3% +30.5% +39.3% + rand -2.8% -2.9% -2.9% -2.8% + sign verify sign/s verify/s + rsa 512 bits0.31s 0.02s -2.7% + rsa 1024bits0.05s + rsa 2048bits+2.4% 0.15s -2.3% + rsa 3072bits0.32s + rsa 4096bits + rsa 7680bits30.2 + rsa 15360 bits5.9 + sign verify sign/s verify/s + dsa 512 bits+4.8% 0.24s -3.9% + dsa 1024bits+2.5% -3.3% +2.4% + dsa 2048bits+2.0% + sign verify sign/s verify/s + 160 bitsecdsa (secp160r1)+100.0%+100.0% -2.2% + 192 bitsecdsa (nistp192) 0.0002s0.0002s -3.6% -3.3% + 224 bitsecdsa (nistp224) 0.s0.0001s + 256 bitsecdsa (nistp256) 0.s0.0001s + 384 bitsecdsa (nistp384) +14.3% 0.0006s -3.2% + 521 bitsecdsa (nistp521) 0.0002s0.0005s + 163 bitsecdsa (nistk163) 0.0002s0.0003s -3.2%
[Touch-packages] [Bug 2056593] Re: [FFE] FIPS compatibility patches
** Description changed: We have an open MR with a handful of FIPS compatibilty changes we wore hoping to get into 24.04. The main purpose of the changes is to detect whether the kernel is running in FIPS mode and adjust the behavior of the library accordingly by loading the correct provider backend and using defaults that are FIPS compliant (no md5, DES etc) instead trying to use non-compliant code paths and crashing. The proposed patches were taken from the OpenSSL version shipped in the FIPS archive at esm.ubuntu.com for 22.04. Having them in the regular archive will reduce the maintenance work significantly. None of the changes should have any impact on running OpenSSL in regular (non-fips) mode. Below is a detailed list of the changes: - d/p/fips/crypto-Add-kernel-FIPS-mode-detection.patch: - This adds a new internal API to determine whether the kernel has been booted - in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE - environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify an - alternative path for the fips_enabled file and is used in tests. - The FIPS_MODULE switch can be used to enable build of the the FIPS provider - module specific parts which are not needed in the OpenSSL library itself. + This adds a new internal API to determine whether the kernel has been booted + in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE + environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify an + alternative path for the fips_enabled file and is used in tests. + The FIPS_MODULE switch can be used to enable build of the the FIPS provider + module specific parts which are not needed in the OpenSSL library itself. - d/p/fips/crypto-Automatically-use-the-FIPS-provider-when-the-kerne.patch: - This automatically configures all library contexts to use the FIPS provider when - the kernel is booted in FIPS mode by: - - Setting "fips=yes" as the default property for algorithm fetches - - Loading and activating the FIPS provider as the fallback provider. + This automatically configures all library contexts to use the FIPS provider when + the kernel is booted in FIPS mode by: + - Setting "fips=yes" as the default property for algorithm fetches + - Loading and activating the FIPS provider as the fallback provider. - If applications load providers via a configuration either because the default - configuration is modified or they override the default configuration, this - disables loading of the fallback providers. In this case, the configuration - must load the FIPS provider when FIPS mode is enabled, else algorithm fetches - will fail + If applications load providers via a configuration either because the default + configuration is modified or they override the default configuration, this + disables loading of the fallback providers. In this case, the configuration + must load the FIPS provider when FIPS mode is enabled, else algorithm fetches + will fail - Applications can choose to use non-FIPS approved algorithms by specifying the - "-fips" or "fips=no" property for algorithm fetches and loading the default - provider. + Applications can choose to use non-FIPS approved algorithms by specifying the + "-fips" or "fips=no" property for algorithm fetches and loading the default + provider. - d/p/fips/apps-speed-Omit-unavailable-algorithms-in-FIPS-mode.patch: - Omit unavailable algorithms in FIPS mode + Omit unavailable algorithms in FIPS mode - d/p/fips/apps-pass-propquery-arg-to-the-libctx-DRBG-fetches.patch - The -propquery argument might be used to define a preference for which provider - an algorithm is fetched from. Set the query properties for the library context - DRBG fetches as well so that they are fetched with the same properties. + The -propquery argument might be used to define a preference for which provider + an algorithm is fetched from. Set the query properties for the library context + DRBG fetches as well so that they are fetched with the same properties. - d/p/fips/test-Ensure-encoding-runs-with-the-correct-context-during.patch: - This test uses 2 library contexts - one context for creating initial test keys, - and then another context (or the default context) for running tests. There is an - issue that during the encoding tests, the OSSL_ENCODER_CTX is created from the - created EVP_PKEYs, which are associated with the library context used to create - the keys. This means that encoding tests run with the wrong library context, - which always uses the default provider. + This test uses 2 library contexts - one context for creating initial test keys, + and then another context (or the default context) for running tests. There is an + issue that during the encoding tests, the OSSL_ENCODER_CTX is created from the + created EVP_PKEYs, which are
[Touch-packages] [Bug 2058017] Re: openssl is not LTO-safe
** Changed in: openssl (Ubuntu) Milestone: None => ubuntu-24.04 ** Changed in: openssl (Ubuntu) Assignee: (unassigned) => Adrien Nader (adrien-n) ** Changed in: openssl (Ubuntu) Status: New => In Progress -- 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/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: In Progress Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. I will add results of "openssl speed" soon (in a few hours). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+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
[Touch-packages] [Bug 2056593] Re: [FFE] FIPS compatibility patches
I did some additional tests too in a noble container. With/without the env var to set the file location, including with the file missing, with/without the env var to force FIPS mode, and using values 0, 1, 42, -42, a. By the way, note that access to these environment variables uses secure_getenv(). -- 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/2056593 Title: [FFE] FIPS compatibility patches Status in openssl package in Ubuntu: New Bug description: We have an open MR with a handful of FIPS compatibilty changes we wore hoping to get into 24.04. The main purpose of the changes is to detect whether the kernel is running in FIPS mode and adjust the behavior of the library accordingly by loading the correct provider backend and using defaults that are FIPS compliant (no md5, DES etc) instead trying to use non-compliant code paths and crashing. The proposed patches were taken from the OpenSSL version shipped in the FIPS archive at esm.ubuntu.com for 22.04. Having them in the regular archive will reduce the maintenance work significantly. None of the changes should have any impact on running OpenSSL in regular (non-fips) mode. Below is a detailed list of the changes: - d/p/fips/crypto-Add-kernel-FIPS-mode-detection.patch: This adds a new internal API to determine whether the kernel has been booted in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify an alternative path for the fips_enabled file and is used in tests. The FIPS_MODULE switch can be used to enable build of the the FIPS provider module specific parts which are not needed in the OpenSSL library itself. - d/p/fips/crypto-Automatically-use-the-FIPS-provider-when-the-kerne.patch: This automatically configures all library contexts to use the FIPS provider when the kernel is booted in FIPS mode by: - Setting "fips=yes" as the default property for algorithm fetches - Loading and activating the FIPS provider as the fallback provider. If applications load providers via a configuration either because the default configuration is modified or they override the default configuration, this disables loading of the fallback providers. In this case, the configuration must load the FIPS provider when FIPS mode is enabled, else algorithm fetches will fail Applications can choose to use non-FIPS approved algorithms by specifying the "-fips" or "fips=no" property for algorithm fetches and loading the default provider. - d/p/fips/apps-speed-Omit-unavailable-algorithms-in-FIPS-mode.patch: Omit unavailable algorithms in FIPS mode - d/p/fips/apps-pass-propquery-arg-to-the-libctx-DRBG-fetches.patch The -propquery argument might be used to define a preference for which provider an algorithm is fetched from. Set the query properties for the library context DRBG fetches as well so that they are fetched with the same properties. - d/p/fips/test-Ensure-encoding-runs-with-the-correct-context-during.patch: This test uses 2 library contexts - one context for creating initial test keys, and then another context (or the default context) for running tests. There is an issue that during the encoding tests, the OSSL_ENCODER_CTX is created from the created EVP_PKEYs, which are associated with the library context used to create the keys. This means that encoding tests run with the wrong library context, which always uses the default provider. These changes are now included in a larger MR with other changes in the same package version: https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+merge/462486 The now-superseded MR is at https://code.launchpad.net/~tobhe/ubuntu/+source/openssl/+git/openssl/+merge/460953 Since OpenSSL just received another big update to 3.0.13 we had to rebase our changes and will have to rerun our install/upgrade tests. A test build is also available at https://launchpad.net/~tobhe/+archive/ubuntu/openssl-test/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2056593/+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
[Touch-packages] [Bug 2058017] Re: openssl is not LTO-safe
** Summary changed: - [FFe] openssl is not LTO-safe + openssl is not LTO-safe -- 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/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: New Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. I will add results of "openssl speed" soon (in a few hours). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+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
[Touch-packages] [Bug 2058017] Re: [FFe] openssl is not LTO-safe
** Description changed: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. - We don't have specific reports on launchpad at the moment but but we - cannot rule out that we're already experiencing miscompilations and - compilers are only pushing this further and further. This is impossible - to know in advance and even security updates could trigger issues. + We don't have specific reports on launchpad at the moment but there has + been at least one issue experienced by the FIPS: the compiler decided a + 0-filled array could be removed and proceeded to do so. In addition to + that, compilers are only pushing this further and further. Issues are + impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled) + - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. + + I will add results of "openssl speed" soon (in a few hours). -- 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/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: New Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at
[Touch-packages] [Bug 2058017] Re: [FFe] openssl is not LTO-safe
** Summary changed: - openssl is not LTO-safe + [FFe] openssl is not LTO-safe -- 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/2058017 Title: [FFe] openssl is not LTO-safe Status in openssl package in Ubuntu: New Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but but we cannot rule out that we're already experiencing miscompilations and compilers are only pushing this further and further. This is impossible to know in advance and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+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
[Touch-packages] [Bug 2058017] [NEW] openssl is not LTO-safe
Public bug reported: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but but we cannot rule out that we're already experiencing miscompilations and compilers are only pushing this further and further. This is impossible to know in advance and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. ** Affects: openssl (Ubuntu) Importance: Undecided Status: New -- 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/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: New Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but but we cannot rule out that we're already experiencing miscompilations and compilers are only pushing this further and further. This is impossible to know in advance and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents
[Touch-packages] [Bug 2030784] Re: Backport Intel's AVX512 patches on openssl 3.0
Thanks a lot for looking at this. The issue seems fixed on my machine. There are currently several changes being prepared for openssl and I think I'd rather batch them considering the state of the CI queue but this will definitely go into Noble. Thanks again. -- 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/2030784 Title: Backport Intel's AVX512 patches on openssl 3.0 Status in openssl package in Ubuntu: Fix Released Bug description: https://github.com/openssl/openssl/pull/14908 https://github.com/openssl/openssl/pull/17239 These should provide a nice performance bonus on recent CPUs, and the patches are fairly self-contained. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2030784/+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
[Touch-packages] [Bug 2056739] Re: apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config"
Hey, I think everything in the gnutls/ directory should be allowed: there can be profiles with arbitrary names (or at least alnum I guess) which define priority/configuration strings that can be used by gnutls applications. I'm not aware of anything else that typically goes there but I haven't checked. I'll have another look today. More generally, there can be the same issue for openssl which has its own abstraction file but isn't included by default AFAIU. A similar issue could apply to ssl_certs since some apps/libraries ship their own cert bundle and could function despite not having access to the system store (I'm looking at you python). I don't know what would be a typical behavior here but I'm pretty sure that the whole range of possible behavior exists in the wild. I'm wondering if I understood the current rules fine because based on my understanding, I would have expected warnings for these too. A noteworthy change is https://bugs.launchpad.net/ubuntu/+source/nss/+bug/2016303 : it would access to /etc/nss . I don't know if NSS silently ignores inaccessible system-wide configuration or not. You might want to include it already. I think all these libraries should probably fail on EPERM. Probably 0 change upstreams accept such a change if it's needed however. :P -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2056739 Title: apparmor="DENIED" operation="open" class="file" profile="virt-aa- helper" name="/etc/gnutls/config" Status in apparmor package in Ubuntu: New Status in chrony package in Ubuntu: New Status in gnutls28 package in Ubuntu: New Status in libvirt package in Ubuntu: New Status in apparmor source package in Noble: New Status in chrony source package in Noble: New Status in gnutls28 source package in Noble: New Status in libvirt source package in Noble: New Bug description: Christian summarizes this after the great reports by Martin: gnutls started to ship forceful disables in pkg/import/3.8.1-4ubuntu3 and added more later. Due to that anything linked against gnutls while being apparmor isolated now hits similar denials, preventing the desired effect of the config change BTW. I think for safety we WANT to always allow this access, otherwise people will subtly not have crypto control about the more important (those isolated) software. Because after the denial I'd expect this to not really disable it in the program linked to gnutls (details might vary depending what they really use gnutls for). I do not nkow of a gnutls abstraction to use, but TBH I'm afraid now fixing a few but leaving this open in some others not spotted. I'd therefore suggest, but we need to discuss, to therefore change it in /etc/apparmor.d/abstractions/base. Therefore I'm adding gnutls (and Adrien) as well as apparmor to the bug tasks. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Merely booting current noble cloud image with "chrony" installed causes this: audit: type=1400 audit(1710152842.540:107): apparmor="DENIED" operation="open" class="file" profile="/usr/sbin/chronyd" name="/etc/gnutls/config" pid=878 comm="chronyd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Running any VM in libvirt causes a new AppArmor violation in current noble. This is a regression, this didn't happen in any previous release. Reproducer: virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 --disk none --wait 0 --name test1 (This is the simplest way to create a test VM. But it's form or shape doesn't matter at all). Results in lots of audit: type=1400 audit(1710146677.570:108): apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config" pid=1480 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 libvirt-daemon 10.0.0-2ubuntu1 apparmor 4.0.0~alpha4-0ubuntu1 libgnutls30:amd64 3.8.3-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056739/+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
[Touch-packages] [Bug 2055304] Re: openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2
There are several reasons a program can skip loading the openssl configuration unfortunately: env vars pointing to another file, apparmor preventing loading, library initilization skipping it, ... Is the program that ignores the openssl configuration file in the Ubuntu archive? Or public? -- 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/2055304 Title: openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2 Status in openssl package in Ubuntu: New Bug description: I get "Closing connection 0 curl: (35) error:0A000126:SSL routines::unexpected eof while reading" accessing some web servers. AFAIS "SSL_OP_IGNORE_UNEXPECTED_EOF" can help here. With 3.2[0] it can be configured in openssl.cnf, whereas 3.0[1] cannot. Would you mind to backport the mini patch[2] to be configured with 3.0, too? Example: $ tail -n 3 /etc/ssl/openssl.cnf [system_default_sect] CipherString = DEFAULT:@SECLEVEL=2 Options = IgnoreUnexpectedEOF [0] https://www.openssl.org/docs/man3.2/man3/SSL_CONF_cmd.html [1] https://www.openssl.org/docs/man3.0/man3/SSL_CONF_cmd.html [2] https://github.com/openssl/openssl/commit/51cf034433d528876f3c235c5150c5acfe88f24d To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2055304/+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
[Touch-packages] [Bug 2055304] Re: openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2
Thanks for continued investigation. A reproducer would be valuable as it would allow me to verify independently the patch is effective, within the limits of the understanding of the situation of course and that can be especially time-consuming when not having access to the remote server. :/ A reproducer here can be along the lines of install ubuntu foo to get nginx bar, configure nginx with TLS and baz and use a given curl command. Right now it's difficult to say if you're missing something since I can't test by myself and compare. A reproducer is also going to be a required proof in practice for the change to be done in any past release. Timeline-wise, either this change gets into 24.04 which is entering Feature Freeze today, or it will wait for the development cycle of 24.10 when openssl is updated to >= 3.2 (probably 3.3). Then only will it be possible to also backport this to 22.04 which I guess is the release you are interested in. -- 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/2055304 Title: openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2 Status in openssl package in Ubuntu: New Bug description: I get "Closing connection 0 curl: (35) error:0A000126:SSL routines::unexpected eof while reading" accessing some web servers. AFAIS "SSL_OP_IGNORE_UNEXPECTED_EOF" can help here. With 3.2[0] it can be configured in openssl.cnf, whereas 3.0[1] cannot. Would you mind to backport the mini patch[2] to be configured with 3.0, too? Example: $ tail -n 3 /etc/ssl/openssl.cnf [system_default_sect] CipherString = DEFAULT:@SECLEVEL=2 Options = IgnoreUnexpectedEOF [0] https://www.openssl.org/docs/man3.2/man3/SSL_CONF_cmd.html [1] https://www.openssl.org/docs/man3.0/man3/SSL_CONF_cmd.html [2] https://github.com/openssl/openssl/commit/51cf034433d528876f3c235c5150c5acfe88f24d To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2055304/+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
[Touch-packages] [Bug 2055422] Re: Please sync xz-utils 5.6.0-0.2 from Debian experimental
Graham pointed out that the upload was actually to unstable and therefore autosync'ed already! I'm going to keep the bug open until it migrates due to the possibility of some testsuite failures. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xz-utils in Ubuntu. https://bugs.launchpad.net/bugs/2055422 Title: Please sync xz-utils 5.6.0-0.2 from Debian experimental Status in xz-utils package in Ubuntu: New Bug description: Xz-utils 5.6.0 was released last Friday. It features a much faster decompression code on all platforms but on x86_64 in particular, it is 60% faster in my testing. It also aligns better current practices of enabling multi-threading by default (always with a default memory limit of 25% of the system physical memory). Sebastian Andrzej Siewior has uploaded it to experimental and after a few fixes for integration (due to extra output on stderr in particular), has uploaded xz-utils 5.6.0-0.2. I expect tests to pass now considering they almost all succeeded with the first upload. I am aware of tweaks to other packages too but I'm not sure they will actually be needed with this new upload and since they relate to pristine-tar and/or dpkg, I think it's probably better to be sure first due to the ongoing migrations. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2055422/+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
[Touch-packages] [Bug 2055422] [NEW] Please sync xz-utils 5.6.0-0.2 from Debian experimental
Public bug reported: Xz-utils 5.6.0 was released last Friday. It features a much faster decompression code on all platforms but on x86_64 in particular, it is 60% faster in my testing. It also aligns better current practices of enabling multi-threading by default (always with a default memory limit of 25% of the system physical memory). Sebastian Andrzej Siewior has uploaded it to experimental and after a few fixes for integration (due to extra output on stderr in particular), has uploaded xz-utils 5.6.0-0.2. I expect tests to pass now considering they almost all succeeded with the first upload. I am aware of tweaks to other packages too but I'm not sure they will actually be needed with this new upload and since they relate to pristine-tar and/or dpkg, I think it's probably better to be sure first due to the ongoing migrations. Thanks. ** Affects: xz-utils (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xz-utils in Ubuntu. https://bugs.launchpad.net/bugs/2055422 Title: Please sync xz-utils 5.6.0-0.2 from Debian experimental Status in xz-utils package in Ubuntu: New Bug description: Xz-utils 5.6.0 was released last Friday. It features a much faster decompression code on all platforms but on x86_64 in particular, it is 60% faster in my testing. It also aligns better current practices of enabling multi-threading by default (always with a default memory limit of 25% of the system physical memory). Sebastian Andrzej Siewior has uploaded it to experimental and after a few fixes for integration (due to extra output on stderr in particular), has uploaded xz-utils 5.6.0-0.2. I expect tests to pass now considering they almost all succeeded with the first upload. I am aware of tweaks to other packages too but I'm not sure they will actually be needed with this new upload and since they relate to pristine-tar and/or dpkg, I think it's probably better to be sure first due to the ongoing migrations. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2055422/+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
[Touch-packages] [Bug 2055304] Re: openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2
Thanks for the report. I am reluctant to backport this as I'm not sure it makes a lot of sense system-wide. Curl upstream didn't seem happy with enabling this work-around even in 2021. It seems the reason to integrate this would be to be able to ignore this despite curl not ignoring it nor offering a way to ignore it. I also don't like that it's the kind of configuration that will linger on systems for years, if not decades. For the distribution, this also means that once the patch is in, it needs to be supported for 15 years. On the other hand, it will get in after 24.04/Noble is released since upstream merged it... Still, I can't make a compelling case in favor of this patch. This is especially troublesome since a change to released versions needs exactly that. Which servers are you experiencing this issue with? -- 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/2055304 Title: openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2 Status in openssl package in Ubuntu: New Bug description: I get "Closing connection 0 curl: (35) error:0A000126:SSL routines::unexpected eof while reading" accessing some web servers. AFAIS "SSL_OP_IGNORE_UNEXPECTED_EOF" can help here. With 3.2[0] it can be configured in openssl.cnf, whereas 3.0[1] cannot. Would you mind to backport the mini patch[2] to be configured with 3.0, too? Example: $ tail -n 3 /etc/ssl/openssl.cnf [system_default_sect] CipherString = DEFAULT:@SECLEVEL=2 Options = IgnoreUnexpectedEOF [0] https://www.openssl.org/docs/man3.2/man3/SSL_CONF_cmd.html [1] https://www.openssl.org/docs/man3.0/man3/SSL_CONF_cmd.html [2] https://github.com/openssl/openssl/commit/51cf034433d528876f3c235c5150c5acfe88f24d To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2055304/+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
[Touch-packages] [Bug 2030784] Re: Backport Intel's AVX512 patches on openssl 3.0
I'm not seeing the issue on 3.2.1. I'm preparing 3.0.13 without the AES patch and will probably deal with it after the feature freeze at the end of the month. -- 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/2030784 Title: Backport Intel's AVX512 patches on openssl 3.0 Status in openssl package in Ubuntu: Fix Released Bug description: https://github.com/openssl/openssl/pull/14908 https://github.com/openssl/openssl/pull/17239 These should provide a nice performance bonus on recent CPUs, and the patches are fairly self-contained. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2030784/+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
[Touch-packages] [Bug 2030784] Re: Backport Intel's AVX512 patches on openssl 3.0
While preparing an update to 3.0.13 for Noble, I started encoutering testsuite failures. The cause is the AES patch combined with 3.0.13 (more specifically with the dupctx patches. The problematic combination looks something like the following: - AES-GCM-enabled-with-AVX512-vAES-and-vPCLMULQDQ - make-inability-to-dup-clone-ciphers-an-error - Add-dupctx-support-to-aead-ciphers - Fix-a-key-repointing-in-various-ciphers (this is probably only needed to avoid merge conflicts and not a cause of the issue) This happens both on Intel and AMD systems which have the corresponding CPU features. I am going to prepare 3.0.13 _without_ the AES patch from here and I will continue to investigate this with upstream's 3.2 (since this is a rare CPU feature, it's possible CI tests don't exercise it). -- 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/2030784 Title: Backport Intel's AVX512 patches on openssl 3.0 Status in openssl package in Ubuntu: Fix Released Bug description: https://github.com/openssl/openssl/pull/14908 https://github.com/openssl/openssl/pull/17239 These should provide a nice performance bonus on recent CPUs, and the patches are fairly self-contained. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2030784/+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
[Touch-packages] [Bug 2052505] Re: Can't install openssl/libssl3 debug package
Thanks for re-trying and reporting! For some (possible) context: there have been some infrastructure issues his week, especially at the beginning of the week: broken services and delays in the pipelines. I was expecting this to be the cause of the issue. -- 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/2052505 Title: Can't install openssl/libssl3 debug package Status in openssl package in Ubuntu: Fix Released Bug description: I'm building an application in docker, using `mcr.microsoft.com/dotnet/runtime:7.0-jammy` (https://github.com/dotnet/dotnet- docker/blob/main/src/runtime/7.0/jammy/amd64/Dockerfile) image, that is using `amd64/buildpack-deps:jammy-curl`(https://github.com/docker- library/buildpack- deps/blob/93d6db0797f91ab674535553b7e0e762941a02d0/ubuntu/jammy/curl/Dockerfile) as base image. In my docker file I added ubuntu debug repositories and install debug packages: ```bash apt-get install -y software-properties-common echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse | \ deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse" | \ tee -a /etc/apt/sources.list.d/ddebs.list apt install ubuntu-dbgsym-keyring apt-get update -y apt-get install -y --no-install-recommends libc6-dbg libssl3-dbgsym openssl-dbgsym libicu70-dbgsym libstdc++6-dbgsym ``` Yesterday I tried and the build isn'T running anymore with the error message: ```output 1.884 Some packages could not be installed. This may mean that you have 1.884 requested an impossible situation or if you are using the unstable 1.884 distribution that some required packages have not yet been created 1.884 or been moved out of Incoming. 1.884 The following information may help to resolve the situation: 1.884 1.887 The following packages have unmet dependencies: 2.072 libssl3-dbgsym : Depends: libssl3 (= 3.0.2-0ubuntu1.13) but 3.0.2-0ubuntu1.14 is to be installed 2.075 openssl-dbgsym : Depends: openssl (= 3.0.2-0ubuntu1.13) but 3.0.2-0ubuntu1.14 is to be installed 2.080 E: Unable to correct problems, you have held broken packages. ``` It looks like the debug symbol oackage for libssl3 and openssl should be updated. I waited 24h for mirror sync, but error still persist. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2052505/+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
[Touch-packages] [Bug 2032577] Re: xz crashed with SIGSEGV in lzma_lzma_optimum_normal
XZ developers have a couple questions regarding this after looking at the trace: - is it reproducible? did it happen several times? - does the machine use ECC memory? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xz-utils in Ubuntu. https://bugs.launchpad.net/bugs/2032577 Title: xz crashed with SIGSEGV in lzma_lzma_optimum_normal Status in xz-utils package in Ubuntu: New Bug description: xz segfaults. More details in https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2032379 From Dmesg.txt on that report [114838.184191] xz[431483]: segfault at 7f9a93f3701a ip 7f9b3f780c1a sp 7f9a957baa50 error 4 in liblzma.so.5.2.5[7f9b3f771000+1b000] ProblemType: Crash ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown DistroRelease: Ubuntu 22.04 ExecutablePath: /usr/bin/xz ExecutableTimestamp: 1649422298 InstallationDate: Installed on 2021-04-09 (863 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) Package: xz-utils 5.2.5-2ubuntu1 ProcCmdline: xz --check=crc32 --threads=0 -c /var/tmp/mkinitramfs-MAIN_E1GbD9 ProcCwd: / ProcEnviron: LC_CTYPE=C.UTF-8 TERM=linux PATH=(custom, no user) LANG=en_GB.UTF-8 ProcVersionSignature: Ubuntu 5.19.0-38.39~22.04.1-generic 5.19.17 SegvAnalysis: Segfault happened at: 0x7f9b3f780c1a:movzbl (%rdi,%r8,1),%r10d PC (0x7f9b3f780c1a) ok source "(%rdi,%r8,1)" (0x7f9a93f3701a) in non-readable VMA region: 0x7f9a90021000-0x7f9a9400 ---p None destination "%r10d" ok Stack memory exhausted (SP below stack segment) SegvReason: reading VMA None Signal: 11 SourcePackage: xz-utils Uname: Linux 5.19.0-38-generic x86_64 UpgradeStatus: Upgraded to jammy on 2023-01-29 (204 days ago) UserGroups: N/A StacktraceTop: bt_find_func (len_limit=64, pos=9137198, cur=0x7f9a943edc3d "", cur_match=4194304, depth=24, son=son@entry=0x7f9a8afbd010, cyclic_pos=748589, cyclic_size=8388609, matches=0x7f9adc0ec324, len_best=11) at ../../../../src/liblzma/lz/lz_encoder_mf.c:483 lzma_mf_bt4_find (mf=0x7f9a9c70, matches=0x7f9adc0ec304) at ../../../../src/liblzma/lz/lz_encoder_mf.c:721 lzma_mf_find (mf=mf@entry=0x7f9a9c70, count_ptr=count_ptr@entry=0x7f9adc0ecb94, matches=matches@entry=0x7f9adc0ec304) at ../../../../src/liblzma/lz/lz_encoder_mf.c:28 lzma_lzma_optimum_normal (position=, len_res=, back_res=, mf=, coder=) at ../../../../src/liblzma/lzma/lzma_encoder_optimum_normal.c:846 lzma_lzma_optimum_normal (position=, len_res=, back_res=, mf=, coder=) at ../../../../src/liblzma/lzma/lzma_encoder_optimum_normal.c:804 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2032577/+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
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done verification-done-jammy ** Tags removed: foundations-triage-discuss -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Kinetic: Won't Fix Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Frank and Grgo, thanks for the verification. That was very helpful. -- 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/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An openssl engine is req. to test the fix. - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. - Install the needed package that allows to exploit the hw crypto resources: sudo apt-get install libica-utils libica? openssl-ibmca - And copy a working sample openssf.cnf file: sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support <=== - try to create a new certificate, using this cmd-line: openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' - The above command must not lead to a 'Segmentation fault (core dumped)', rather than create a proper certificate file. Also watch /var/log/syslog / journalctl for more details. - Upgrade not only the openssl package itself, but also libssl3, before verification. - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2)
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Thanks a lot for the verification Simon! I looked at the test results and I believe failed tests are all fine: - diffoscope: pyhon "ModuleNotFoundError: No module named 'tests.utils'" - dotnet*: complains that this dotnet is not tested for 24.04 (yes, 24.04); this system of keeping a matrix of host/targets compatibility is being removed upstream due to being impossible to maintain (confirmed by Dominik) - ganeti: same failure as with the iptables SRU - linux-*: timed out building the kernel - ruby3.0: expired certificates in testsuite For the following packages, I re-tried the tests and they succeeded: - puma: retried twice and passed; at least one occurrence of the same failure - python-bonsai: retried; passing now; there have been various errors in this package that disappear on re-try - seqkit: retried; and passing I guess since it disappeared; there's a (long) history of this test failing - systemd: retried; timeouts which don't really seem to be related to openssl, or at least I couldn't spot an error, same issues can be seen in several other logs -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better.
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
As expected, it wasn't very easy to create a reproducer since the openssl tool couldn't be used and it required introducing errors in lower layers. Moreover the CMS_dataFinal symbol cannot be overriden in a meaningful way, probably either due to LTO or symbol visibility. Fortunately it was still possible to do it through GDB even though it couldn't locate the symbol at first (hence the message "Function "CMS_dataFinal" not defined.") # apt-get install -y gdb # cat > gdb_commands << EOF > set breakpoint pending on break CMS_dataFinal r return (int) 0 c q EOF # echo foo > mail.txt # openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -sha256 -days 30 # echo use "1234" as password and press enter for each subsequent question # gdb --return-child-result --batch-silent --command=gdb_commands --args openssl cms -sign -in mail.txt -out mail.msg -signer cert.pem -inkey key.pem -noindef -nodetach -passin pass:1234; echo $? Function "CMS_dataFinal" not defined. 0 # echo edit sources.list and apt install -t jammy-proposed libssl3 # # gdb --return-child-result --batch-silent --command=gdb_commands --args openssl cms -sign -in mail.txt -out mail.msg -signer cert.pem -inkey key.pem -noindef -nodetach -passin pass:1234; echo $? Function "CMS_dataFinal" not defined. 80FBF0F7FF7F:error:1767:CMS routines:CMS_final:cms datafinal error:../crypto/cms/cms_smime.c:890: 3 As can be seen, after the update, the return code is non-0, indicating the error was properly bubbled up. -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Kinetic: Won't Fix Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
Gil, can you do the verification? Thanks. -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Kinetic: Won't Fix Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Thanks for the review and upload. I have a similar take on the patches in this series and I believe it would be very difficult and riskier to try to skip some of the patches in this series which has seen real-world use as a whole, starting with openssl >= 3.0.4 (which we started shipping in lunar). -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which both saturates CPU, and "hides" latencies that are relatively low. Finally, there are positive reports on github. Unfortunately they are not always completely targeted at these patches only and therefore I will not link directly to them but they have also been
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
I'm attaching an updated debdiff. - remove left-over patches for a bug that we decided to not handle as part of this SRU (patches were already unlisted from d/p/series) - added Bug-Ubuntu entries to patches PPA is the same. New build is at https://launchpad.net/~adrien-n/+archive/ubuntu/jammy- openssl-2033422-sru/+sourcepub/15684316/+listing-archive-extra . ** Patch added: "openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+attachment/5737782/+files/openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Here is an updated version. I've dropped the extra patch for #1994165 and fixed the changelog where I had swapped comments for two of the patches. I've created a new PPA at https://launchpad.net/~adrien-n/+archive/ubuntu/jammy- openssl-2033422-sru because the version is unchanged (there has been no new openssl security update). ** Patch added: "openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+attachment/5736379/+files/openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the three bug reports and I am attaching the debdiff here only for all three. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture-dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which both saturates CPU, and
[Touch-packages] [Bug 2030784] Re: Backport Intel's AVX512 patches on openssl 3.0
I tested this patch set on a Zen 4 machine too and saw roughly similar speedups. And before someone asks: no, I'm not testing that on Via CPUs! -- 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/2030784 Title: Backport Intel's AVX512 patches on openssl 3.0 Status in openssl package in Ubuntu: Fix Released Bug description: https://github.com/openssl/openssl/pull/14908 https://github.com/openssl/openssl/pull/17239 These should provide a nice performance bonus on recent CPUs, and the patches are fairly self-contained. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2030784/+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
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
Sometimes I don't understand what happens when I attempt to reply by
mail...
Anyway...
The affected code is in libcrypto which I think sees fewer important security
fixes. Therefore it's possible to build it and put it in your library search
path. This should fix the issue without being too terrible wrt security updates.
I still think that setting the key size in the caller program is better
if possible however. It's slightly more involved upfront though (but it
could pay up in the end).
I'll prepare a PPA on tomorrow with only this change on tomorrow; I will
probably add a few things to prevent using the package directly however
since I expect the proper approach would be to 'dpkg -x' the package or
equivalent and use its libcrypto.so and LD_LIBRARY_PATH or similar
specifically when needed.
--
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 was the fourth in a series of 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+wIABFla
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
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
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
[Touch-packages] [Bug 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
There aren't many ways to make localtime() fail and we still don't know
how this happened in this case. We expect this happens maybe on a 32-bit
machine. You can't have a really huge value in btmp anyway because
everything is stored on 32-bit signed integers but maybe seconds are
negative or microseconds are more than a million (or negative?). It's
very difficult to tell and I think we could reproduce the issue but we
might also find several ways to get the same behavior.
I'm also wondering if the bug is really in pam _if_ the behavior is
different between 32-bit and 64-bit arches. This could be worth
investigating.
Do we have a *tmp file that exhibit the issue? I think it would be worth
diving into the binary to see if anything stands out.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in pam package in Ubuntu:
New
Status in pam package in Fedora:
Fix Released
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (_time, _buf)) != NULL) {
316- strftime (the_time, sizeof (the_time),
317- /* TRANSLATORS: "strftime options for date of last
login" */
--
574-
575- lf_time = utuser.ut_tv.tv_sec;
576: tm = localtime_r (_time, _buf);
577- strftime (the_time, sizeof (the_time),
578- /* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/2045250/+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
[Touch-packages] [Bug 2030784] Re: Backport Intel's AVX512 patches on openssl 3.0
Thanks a lot for the tests, that's very appreciated. I ran that on my laptop (11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz) which quite surprisingly has all these CPU features. Mostly idle, dynamic CPU governor but no thermal throttling at all (and if there were, it would probably slow down the AVX-512 code anyway), and tests are long enough for CPU governors to not matter much. * AES-128-GCM | AES-256-GCM - Baseline - Requires VAES and VPCMULQDQ features present on ICX or newer platform. This should be the most performant flow. AES-128-GCM 855360.29k 3158479.88k 6093932.91k 8905067.37k 13336828.91k 13788498.58k - Individual VAES Disabled and VPCLMULQDQ Disabled should fallback to AVX AESNI flow and should have equivalent performance AES-128-GCM 785422.85k 1936140.78k 4404423.77k 6481577.18k 7732716.48k 7873213.39k AES-128-GCM 790775.41k 1942054.64k 4404868.20k 6484287.87k 7711803.10k 7778795.52k - AESNI and VAESNI Disabled should fallback to 'C code' performance AES-128-GCM 150183.11k 167807.25k 598198.71k 662922.19k 681574.40k 678182.91k * RSA 2K/3K/4K Sign Performance - Baseline - Requires AVX512F, AVX512VL, AVX512DQ, and AVX512IFMA features on ICX or newer platform. This should be the most performant flow. rsa 2048 bits 0.000246s 0.15s 4057.2 65278.3 rsa 3072 bits 0.000701s 0.32s 1426.4 31247.7 rsa 4096 bits 0.001434s 0.55s697.4 18052.7 - Individual AVX512F, AVX512VL, and AVX512IFMA features should yield equivalent performance. This flow will use the ADOX/ADCX/MULX RSA flow. rsa 2048 bits 0.000523s 0.15s 1910.4 65748.2 rsa 3072 bits 0.001579s 0.32s633.3 31158.1 rsa 4096 bits 0.003529s 0.55s283.4 18093.6 rsa 2048 bits 0.000524s 0.15s 1909.0 66310.8 rsa 3072 bits 0.001577s 0.32s634.1 31309.7 rsa 4096 bits 0.003568s 0.55s280.2 18120.4 rsa 2048 bits 0.000523s 0.15s 1913.3 65234.3 rsa 3072 bits 0.001583s 0.32s631.7 31094.6 rsa 4096 bits 0.003607s 0.55s277.3 18076.8 rsa 2048 bits 0.000524s 0.15s 1907.6 66299.6 rsa 3072 bits 0.001577s 0.32s634.1 31214.4 rsa 4096 bits 0.003586s 0.55s278.9 18096.1 We see the expected behavior (AFAIU, all features must be available at the same time for the changes to have effect). I'm not comparing everything number by number because I don't think we're looking for specific percentages of improvements. Overall we see up to ~2.4 performance improvement and we always see large improvements (double digit percentages). As a control I also ran that on lunar, therefore without the patches (I acknowledge this is not the same openssl version and there are also other changes but I do not think this matters here). # AES-128-GCM | AES-256-GCM - Baseline - Requires VAES and VPCMULQDQ features present on ICX or newer platform. This should be the most performant flow. AES-128-GCM 782474.44k 1938211.66k 4430867.84k 6402298.54k 7685819.33k 7840186.37k - Individual VAES Disabled and VPCLMULQDQ Disabled should fallback to AVX AESNI flow and should have equivalent performance AES-128-GCM 750028.44k 1926234.78k 4365867.67k 6383893.16k 7742842.78k 7843146.41k AES-128-GCM 786910.34k 1934779.33k 4421411.45k 6389114.88k 7650086.87k 7797479.86k - AESNI and VAESNI Disabled should fallback to 'C code' performance AES-128-GCM 147889.72k 167843.85k 599710.04k 663642.45k 679072.96k 680631.91k # RSA 2K/3K/4K Sign Performance - Baseline - Requires AVX512F, AVX512VL, AVX512DQ, and AVX512IFMA features on ICX or newer platform. This should be the most performant flow. rsa 2048 bits 0.000247s 0.15s 4050.8 66072.6 rsa 3072 bits 0.001596s 0.32s626.5 31144.2 rsa 4096 bits 0.003534s 0.56s282.9 18003.6 - Individual AVX512F, AVX512VL, and AVX512IFMA features should yield equivalent performance. This flow will use the ADOX/ADCX/MULX RSA flow. rsa 2048 bits 0.000528s 0.15s 1892.3 66008.3 rsa 3072 bits 0.001573s 0.32s635.6 31094.2 rsa 4096 bits 0.003534s 0.55s282.9 18073.8 rsa 2048 bits 0.000522s 0.15s 1914.7 65763.4 rsa 3072 bits 0.001575s 0.32s635.0 31237.8 rsa 4096 bits 0.003530s 0.55s283.2 18093.1 rsa 2048 bits 0.000522s 0.15s 1917.4 65826.2 rsa 3072 bits 0.001575s 0.32s635.0 31177.2 rsa 4096 bits 0.003549s 0.55s281.8 18109.9 rsa 2048 bits 0.000522s 0.15s 1915.1 65760.4 rsa 3072 bits 0.001575s 0.32s635.0 31180.2 rsa 4096 bits 0.003538s 0.55s282.6 18109.9 We can see there are no change with the CPU feature flags, except for the test that disables AESNI, in which case the performance is the same in lunar and mantic. That the CPU feature flags don't change the performance except i the one aforementioned case, indicate that these patches are responsible for the large performance increase we have seen. We can also see that they don't otherwise
[Touch-packages] [Bug 2044795] Re: Please merge openssl 3.1.4-2 from debian unstable
Openssl's support policy means we won't be using a non-LTS version in Ubuntu. There's a small window where we might use a non-LTS version provided we are sure we can upgrade to an LTS version of openssl in time for our own LTS but at the moment this situation has not happened yet. Openssl 3.1 is not an LTS, nor is 3.2 (released a few days ago), and it is not known if 3.3 will be. By the way, 3.3 should be released in April, almost in time for our LTS, but again, we don't know if it will also be an LTS release. As a consequence, we are unfortunately most likely going with 3.0 in 24.04, and every subsequent ubuntu release until we know we will have an LTS in time for our 26.04 (because we can't "downgrade" openssl version for our LTS releases). In the future it is possible that we introduce "openssl-latest" or something like that in order to track most recent releases but without any support guarantee. This would be a completely separate package. In any case, I hadn't noticed that 3.1.* had been uploaded to Debian unstable. I was assuming that the debian maintainers would stick to 3.0 for the same reasons as I outlined above. It's possible they're betting they will have an openssl LTS release in time for trixie's release since trixie might be out in 2025 and by that time openssl 3.0 will roughly reach EOL, and a new openssl LTS would be needed. I guess we'll have to discuss which openssl version to use post-24.04 but probably not before 24.04 is released. I'm going to re-write this report as something post 24.04 since we can't do anything before 24.04 sadly. ** Changed in: openssl (Ubuntu) Milestone: None => later ** Summary changed: - Please merge openssl 3.1.4-2 from debian unstable + Please merge openssl from debian unstable ** Changed in: openssl (Ubuntu) Status: New => Confirmed -- 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/2044795 Title: Please merge openssl from debian unstable Status in openssl package in Ubuntu: Confirmed Bug description: tracking bug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2044795/+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
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
Apologies for not answering earlier; I wasn't available when I first saw
your message.
FWIW, there's just been another report of the same issue with a
different scenario but that's half-way between the "streaming" case and
the "data at rest" one.
The reason this fix is difficult to integrate in a stable release is
because while we know we would introduce breakage, we do not and cannot
know how much. Imagine even 100 Jammy machines which can talk together
today; that's quite expected because they're on the same release. This
change would break that unless every machine is upgraded at once which
is not the case by default due to phasing of updates (and we want to
phase openssl updates slowly because it's a very central component).
While I really sympathetize with your issue, this is the stance of the
Ubuntu project. Both including the fix and not including the fix are
problematic unfortunately.
One additional reason to not include the fix is that we're now close to
Ubuntu 24.04. I realize you've reported this over a year ago but
analysis, preparing a new verion, and the SRU process all take time.
This is especially true for openssl which is central and which updates
have caused issues several times.
Ultimately I'd like to be able to keep Ubuntu releases updated with the
latest openssl versions (no jump from 3.x to 3.x+1 though, merely 3.x.y
to 3.x.y+1). This is not done at the moment because incompatibilities
and issues in openssl are often found late but are also very painful. In
order to do these, I will have to apply the same analysis and criteria
to every change in the openssl releases to ensure package upgrades are
safe and uneventful. Had this been in place for 22.04, this change would
likely have been integrated when it was released in June because that
was very close to the initial 22.04 release. If we want this to happen,
we need to draw the line somewhere and stick to it. Unfortunately this
change is on the other side of the line
That's not to say that we cannot do anything for tinc or for others
affected packages but rather that it won't be done in openssl.
I see two ways to improve this, tinc side.
1) Switch to another cipher. Blowfish uses a 64-bit block size which is
small and limits how much data can be safely encrypted with the same key
(
https://en.wikipedia.org/wiki/Blowfish_(cipher)#Weakness_and_successors
). I guess this requires cooperation from the server which you might not
control but it is the best long-term solution (and would also help
performance because computing a MAC on top of BF is surprisingly
expensive, and re-keying every n GB stalls data transfers and incurs a
spike in latency).
2) Modify tinc because there's apparently a portable work-around as I've
mentioned in
https://github.com/gsliepen/tinc/issues/414#issuecomment-1741038601 . I
think there's more context on the github openssl bug tracker. My time is
scarce until the end of the year but I will gladly help with the
packaging if needed. I don't know if it could be uploaded because there
would be the same compatibility concern, this time with servers on
22.04. A PPA might be more appropriate and not too inconvenient since
tinc development has stalled while openssl gets security updates every
few months. It might also be possible to add a new ciphername/option
just for that but I don't know how much work that would be without
looking at tinc's code. Let me know if you are able to spend some time
on this.
By the way, even though a change in the C code just for tinc seems
annoying, the knowledge gained could be used for other packaes and
workloads too.
--
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 was the fourth in a series of 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
[Touch-packages] [Bug 2044391] Re: Blowfish decryption failure because of incorrect key length
*** This bug is a duplicate of bug 1990216 *** https://bugs.launchpad.net/bugs/1990216 ** This bug has been marked a duplicate of bug 1990216 backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy -- 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/2044391 Title: Blowfish decryption failure because of incorrect key length Status in openssl package in Ubuntu: New Bug description: The version of OpenSSL in Jammy (3.0.2) is affected by this issue: https://github.com/openssl/openssl/issues/18359. The upshot is that ciphertext created in Jammy cannot be decrypted by unaffected versions of OpenSSL and vice versa. For example, here we encrypt a plaintext in Jammy: $ cat plaintext.txt The quick brown fox jumps over the lazy dog $ openssl enc -provider legacy -bf-cfb -e -in plaintext.txt -out ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1 $ cat ciphertext.asc tBL52uAegjMw+DQLL1ipaXQjDnX0KK72QyqMxU1MbuSIfchivPj/JOGWUOU= $ openssl enc -provider legacy -bf-cfb -d -in ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1 The quick brown fox jumps over the lazy dog If we then try to decrypt it in Debian Sid, we get: $ openssl enc -provider legacy -bf-cfb -d -in ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1 hex string is too short, padding with zero bytes to length �;S��\h<�Vɦyʄ(�g`Hrm^�[��u �"f�S�-9�u This has been fixed upstream here: https://github.com/openssl/openssl/commit/1b8ef23e68b273bb5e59f60df62251153f24768d To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2044391/+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
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
Indeed, there is an "extra" change which I saw fit to include after reviewing the change with care. Replicating the issue directly involves using the openssl C APIs because higher-level interfaces like the command-line ones prevent calling the affected code in a way that will trigger the issue. This significantly increases the effort required to write the testcase. I don't think upstream wrote one either although that is their habit nowadays but it's been some time and I will have to look at it again. Removing (b) wouldn't cause a security issue and it seems (a) is enough to fix the functional issue that has been reported. On the other hand this is a diff from current upstream versions, it will require new tests and the (a+b) changes have seen a lot of use worlwide by now. When including (b), I knew that it was probably not strictly required and I'm fine with removing it even though I would prefer to keep it for the above reasons. -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Kinetic: Won't Fix Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
As you mention, it's difficult to test with this reproducer specifically since it's specialized hardware and I've largely had to rely on testing from the proxied persons who also have interests and duties in this working well. The issue also appears without the specific hardware when using providers for some functions but openssl 3.0 providers are recent and not very widely used so there aren't many one that fit either and the verification/setup is correspondingly high. On the bright side, the potential for damage is low due to the small userbase. One last thing: I don't know if this could work less well than right now since they get crashes. The "engines-1.1" is not necessarily a concern: libengine-gost- openssl/libengine-gost-openssl1.1 was/were putting files in a similar place without issue IIRC. I don't have a good example to show because the package currently for jammy puts it in / directly... . In any case, the path should be configured and the actual location isn't really an issue. You can see the configuration on https://sysos.ru/archives/589 (russian, search for "openssl_def"; I have seen non-russian links too but I can't find them again). The package for the SRU is already in -proposed so it should be possible to test already. It's (very) late here though so I'll come back to this and the tests tomorrow. Thanks for the review, comments, and testcase. -- 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/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress 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 three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. The issue has also been reported independently and with another engine (devcrypto). The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code:
[Touch-packages] [Bug 2043713] Re: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed
Thanks for looking more deeply than I did. I guess I'll upload both to my PPA, using whichever version is in -proposed right now. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2043713 Title: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed Status in apport package in Ubuntu: New Bug description: autopkgtests are pretty reliably failing[1] on armhf due to the following (single) test failure: 638s === FAILURES === 638s TestApportValgrind.test_valgrind_min_installed 638s 638s self = 638s 638s def test_valgrind_min_installed(self): 638s """Valgrind is installed and recent enough.""" 638s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"] 638s (ret, out, err) = self._call(cmd) 638s > self.assertEqual(err, "") 638s E AssertionError: "==2474== Invalid write of size 4\n==2474[1064 chars]= \n" != '' 638s E Diff is 1134 characters long. Set self.maxDiff to None to see it. 638s 638s tests/integration/test_apport_valgrind.py:43: AssertionError This could be related to valgrind functionality being different on armhf, it could also be related to integer sizes internally on armhf. I haven't looked too deeply into it. [1] https://autopkgtest.ubuntu.com/packages/a/apport/noble/armhf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2043713/+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
[Touch-packages] [Bug 2043713] Re: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed
That looks a lot like the -fstack-clash-protection issue we've been having recently for other packages on armhf. dpkg 1.22.1ubuntu3 should fix this ( https://launchpad.net/ubuntu/+source/dpkg/1.22.1ubuntu3 ) The place where I've written the most details about this is https://code.launchpad.net/~adrien-n/ubuntu/+source/dpkg/+git/dpkg/+merge/456181 . If you want I can also upload your package to my test PPA. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2043713 Title: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed Status in apport package in Ubuntu: New Bug description: autopkgtests are pretty reliably failing[1] on armhf due to the following (single) test failure: 638s === FAILURES === 638s TestApportValgrind.test_valgrind_min_installed 638s 638s self = 638s 638s def test_valgrind_min_installed(self): 638s """Valgrind is installed and recent enough.""" 638s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"] 638s (ret, out, err) = self._call(cmd) 638s > self.assertEqual(err, "") 638s E AssertionError: "==2474== Invalid write of size 4\n==2474[1064 chars]= \n" != '' 638s E Diff is 1134 characters long. Set self.maxDiff to None to see it. 638s 638s tests/integration/test_apport_valgrind.py:43: AssertionError This could be related to valgrind functionality being different on armhf, it could also be related to integer sizes internally on armhf. I haven't looked too deeply into it. [1] https://autopkgtest.ubuntu.com/packages/a/apport/noble/armhf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2043713/+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
[Touch-packages] [Bug 2044391] Re: Blowfish decryption failure because of incorrect key length
I'm going to mark this as duplicate of another bug which I have an overdue answer to provide. But one important question: what is your actual usecase that is negatively impacted? -- 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/2044391 Title: Blowfish decryption failure because of incorrect key length Status in openssl package in Ubuntu: New Bug description: The version of OpenSSL in Jammy (3.0.2) is affected by this issue: https://github.com/openssl/openssl/issues/18359. The upshot is that ciphertext created in Jammy cannot be decrypted by unaffected versions of OpenSSL and vice versa. For example, here we encrypt a plaintext in Jammy: $ cat plaintext.txt The quick brown fox jumps over the lazy dog $ openssl enc -provider legacy -bf-cfb -e -in plaintext.txt -out ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1 $ cat ciphertext.asc tBL52uAegjMw+DQLL1ipaXQjDnX0KK72QyqMxU1MbuSIfchivPj/JOGWUOU= $ openssl enc -provider legacy -bf-cfb -d -in ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1 The quick brown fox jumps over the lazy dog If we then try to decrypt it in Debian Sid, we get: $ openssl enc -provider legacy -bf-cfb -d -in ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1 hex string is too short, padding with zero bytes to length �;S��\h<�Vɦyʄ(�g`Hrm^�[��u �"f�S�-9�u This has been fixed upstream here: https://github.com/openssl/openssl/commit/1b8ef23e68b273bb5e59f60df62251153f24768d To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2044391/+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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] This SRU contains THREE changes which are listed in the section below. [Meta] - This bug is part of a series of four bugs for a single SRU. + This bug is part of a series of three bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. - This SRU addresses four issues with Jammy's openssl version: + This SRU addresses three issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) - The SRU information has been added to the four bug reports and I am - attaching the debdiff here only for all four. + The SRU information has been added to the fthree bug reports and I am + attaching the debdiff here only for all three. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture- dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which both saturates CPU, and "hides" latencies that are relatively low. Finally, there are positive reports on github. Unfortunately they are not always completely targeted at these patches only and therefore I will not link directly to them but they have also been encouraging. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to these changes was reported on launchpad or upstream. However, it is possible
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
Hi Nathan,
Sorry, I didn't have enough time to comment here before a few days of
vacation.
This one is indeed not in the SRU at the moment. The description edit
itself did not make much sense.
I first discussed this topic with Simon but then also with Steve
Langasek, with others attending the same meeting. The general agreement
is that bugs when setting up something for the first time are far less
severe than bugs that appear afterwards. One major issue here is
everything that exists but that we don't know of, including custom
software or scripts.
As far as I'm concerned, I evaluate this roughly like you did but I
cannot do something that the SRU team is against (I also trust them and
their experience, even when my feeling is different).
Lastly, 22.04 was released more than 18 months ago and 24.04 is around
the corner; 18 months is a long delay to introduce breaking changes and
by now people probably expect very few changes to 22.04.
As far as I understand, tinc could fairly easily work around this issue
by explicitely setting the key size before doing operations. This is the
safest approach. It might even be faster than waiting for the SRU and
corresponding phased updates.
** Description changed:
=== SRU information ===
[Meta]
- This bug is part of a series of three bugs for a single SRU.
+ This bug was the fourth in a series of 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+wIABFla
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
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
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.
[Touch-packages] [Bug 1962549] Re: openssl cms -decrypt doesn't work properly when using an engine
I don't know why LP expired this bug since you commented after I changed the its status... Anyway, I'm going to mark it as New again. Unfortunately, I haven't had time to try to reproduce this again and I won't have time before at least two weeks due to some time off and Canonical events. It would be tremendously helpful if you manage to directly provide the comments for the steps. ** Changed in: openssl (Ubuntu) Status: Expired => New -- 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/1962549 Title: openssl cms -decrypt doesn't work properly when using an engine Status in openssl package in Ubuntu: New Bug description: I'm using: bsci@ip-10-132-42-225:~/test$ lsb_release -rd Description:Ubuntu 20.04.3 LTS Release:20.04 bsci@ip-10-132-42-225:~/test$ apt-cache policy openssl openssl: Installed: 1.1.1f-1ubuntu2.10 Candidate: 1.1.1f-1ubuntu2.10 Version table: *** 1.1.1f-1ubuntu2.10 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 1.1.1f-1ubuntu2.8 500 500 http://archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 1.1.1f-1ubuntu2 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages I have a private EC key held in a TPM 2.0 platform hierarchy. I'm encrypting a message like this: openssl cms -encrypt -in message.txt -out message.cipher transport.pem Here, transport.pem is the cert. for the EC key held in the TPM. I'm attempting to decrypt like this: openssl cms -decrypt -in message.cipher -out /dev/stdout -inkey 0x8181 -keyform engine -engine tpm2tss -recip transport.pem Instead of seeing the original message text, I'm getting the following error: engine "tpm2tss" set. Error decrypting CMS using private key 139626757388096:error:1010107D:elliptic curve routines:ecdh_simple_compute_key:missing private key:../crypto/ec/ecdh_ossl.c:61: It seems that the code is expecting the actual private key instead of using the key held in the TPM? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1962549/+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
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
** Description changed:
=== SRU information ===
[Meta]
- This bug is part of a series of four bugs for a single SRU.
+ This bug is part of a series of three 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+wIABFla
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
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
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=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=04ef023920ab08fba214817523fba897527dfff0
=== Original
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
** Description changed: === SRU information === [Meta] - This bug is part of a series of four bugs for a single SRU. + This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Kinetic: Won't Fix Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
** Description changed: === SRU information === [Meta] - This bug is part of a series of four bugs for a single SRU. + This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. The issue has also been reported independently and with another engine (devcrypto). The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. Found module linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e Found module libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731 Found module ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08 Found module ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] - This SRU contains FOUR changes which are listed in the section below. + This SRU contains THREE changes which are listed in the section below. [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections + - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections (this one) The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . To test, follow these steps: - run "time python3 main.py" # using the aforementioned main.py script - apt install -t jammy-proposed libssl3 - run "time python3 main.py" - compare the runtimes for the two main.py runs You can run this on x86_64, Raspberry Pi 4 or any machine, and get a very large speed-up in all cases. The improvements are not architecture- dependant. Using this changeset, I get the following numbers for ten runs on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which both saturates CPU, and "hides" latencies that are relatively low. Finally, there are positive reports on github. Unfortunately they are not always completely targeted at these patches only and therefore I will not link directly to them but they have also been encouraging. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to these changes was reported on launchpad or upstream. However, it is possible that there were more patch dependencies than these in either 3.0.3 or 3.0.4. In that case there
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . - Using this, I get the following numbers for ten runs on my laptop: + + To test, follow these steps: + - run "time python3 main.py" # using the aforementioned main.py script + - apt install -t jammy-proposed libssl3 + - run "time python3 main.py" + - compare the runtimes for the two main.py runs + + You can run this on x86_64, Raspberry Pi 4 or any machine, and get a + very large speed-up in all cases. The improvements are not architecture- + dependant. + + Using this changeset, I get the following numbers for ten runs on my + laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which both saturates CPU, and "hides" latencies that are relatively low. Finally, there are positive reports on github. Unfortunately they are not always completely targeted at these patches only and therefore I will not link directly to them but they have also been encouraging. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to these changes was reported on launchpad or upstream. However, it is possible that there were more patch dependencies than these in either 3.0.3 or 3.0.4. In that case there could be problems. [Patches] The patches come directly from upstream and apply cleanly.
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Forgot to upload the latest debdiff. ** Patch added: "openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff" https://bugs.launchpad.net/ubuntu/jammy/+source/openssl/+bug/2033422/+attachment/5713594/+files/openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers for ten runs on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which both saturates CPU, and "hides" latencies that are relatively low. Finally, there are positive reports on github. Unfortunately they are not always completely targeted at these patches only and therefore I will not link directly to them but they have also been encouraging. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to these changes was reported on launchpad or upstream. However, it is possible that there were more patch
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). The patch related to blowfish presents an annoying situation: jammy's openssl creates incompatible files and cannot read other files but fixing it will lead to files created on jammy so far to become unreadable. Fortunately, blowfish is long-deprecated and applications can be improved to handle this situation if the need arises in practice. This is stated in the SRU information in the bug and in d/changelog. The current situation in Jammy could be a security issue but due to the aforementioned deprecation, the low usage of blowfish and the fact that upstream didn't consider this worthy of a security notice, we (this includes the security team) chose not to pursue that path either. I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . - - Simply run "time python3 main.py". The script does a GET for - https://www.google.com/humans.txt . You can replace this URI in the script with any other resource (I've also used something on my LAN with no timing difference). Since this is a performance change, you need to remember to get performance numbers before updating. You can run this test on any platform: the performance issue is purely logical and not tied to a CPU architecture. The improvement is very large and always reproductible with very little variability on a given machine; there is therefore no need to use a dedicated and fully idle machine using a constant-frequency CPU governor while ensuring temperatures do not cause throttling. - - Using this, I get the following numbers on my x86 laptop: + Using this, I get the following numbers for ten runs on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away.
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [ATTENTION] This SRU contains FOUR changes which are listed in the section below. [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). The patch related to blowfish presents an annoying situation: jammy's openssl creates incompatible files and cannot read other files but fixing it will lead to files created on jammy so far to become unreadable. Fortunately, blowfish is long-deprecated and applications can be improved to handle this situation if the need arises in practice. This is stated in the SRU information in the bug and in d/changelog. The current situation in Jammy could be a security issue but due to the aforementioned deprecation, the low usage of blowfish and the fact that upstream didn't consider this worthy of a security notice, we (this includes the security team) chose not to pursue that path either. I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . - Using this, I get the following numbers on my laptop: + + Simply run "time python3 main.py". The script does a GET for + https://www.google.com/humans.txt . You can replace this URI in the script with any other resource (I've also used something on my LAN with no timing difference). Since this is a performance change, you need to remember to get performance numbers before updating. You can run this test on any platform: the performance issue is purely logical and not tied to a CPU architecture. The improvement is very large and always reproductible with very little variability on a given machine; there is therefore no need to use a dedicated and fully idle machine using a constant-frequency CPU governor while ensuring temperatures do not cause throttling. + + Using this, I get the following numbers on my x86 laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === + [ATTENTION] + This SRU contains FOUR changes which are listed in the section below. + [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). The patch related to blowfish presents an annoying situation: jammy's openssl creates incompatible files and cannot read other files but fixing it will lead to files created on jammy so far to become unreadable. Fortunately, blowfish is long-deprecated and applications can be improved to handle this situation if the need arises in practice. This is stated in the SRU information in the bug and in d/changelog. The current situation in Jammy could be a security issue but due to the aforementioned deprecation, the low usage of blowfish and the fact that upstream didn't consider this worthy of a security notice, we (this includes the security team) chose not to pursue that path either. I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which both saturates CPU, and "hides" latencies that are relatively low. Finally, there are positive reports on github. Unfortunately they are not always completely targeted at these patches only and therefore I will not link directly to them but they have also been encouraging. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Hi Lucas, Sorry, this is part of an SRU with 4 patches but that we've decided to hold back for a bit (a few days after the current release). I've removed ubuntu-sponsors from the "main" LP bug (link near the top of the bug report) but not from the others. I'll do it now and I think maybe it's better to only add ~ubuntu-sponsors to that main ticket. -- 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/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress 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] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. The issue has also been reported independently and with another engine (devcrypto). The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Removed ~ubuntu-sponsors for a few days while a few things settle. -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New 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. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). The patch related to blowfish presents an annoying situation: jammy's openssl creates incompatible files and cannot read other files but fixing it will lead to files created on jammy so far to become unreadable. Fortunately, blowfish is long-deprecated and applications can be improved to handle this situation if the need arises in practice. This is stated in the SRU information in the bug and in d/changelog. The current situation in Jammy could be a security issue but due to the aforementioned deprecation, the low usage of blowfish and the fact that upstream didn't consider this worthy of a security notice, we (this includes the security team) chose not to pursue that path either. I have also pushed the code to git (without any attempt to make it git-ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which both saturates CPU, and "hides" latencies that are relatively low. Finally, there are positive reports on github. Unfortunately they are not always completely targeted at these patches only and therefore I will not link directly to them but they have also been
[Touch-packages] [Bug 2039142] Re: openssl v3.0.2 is not work with dynamic engine libengine-gost-openssl1.1
** Changed in: openssl (Ubuntu) Status: New => 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/2039142 Title: openssl v3.0.2 is not work with dynamic engine libengine-gost- openssl1.1 Status in openssl package in Ubuntu: Incomplete Bug description: Hello We use from a source code the gost engine for a check certificates chains. But openssl the version 3.0.2 is not correct load dynamic engines. openssl return error "40D7F65B7F7F:error:1280006A:DSO support routines:dlfcn_bind_func:could not bind to the requested symbol name:../crypto/dso/dso_dlfcn.c:188:symname(EVP_PKEY_base_id): /usr/lib/x86_64-linux-gnu/engines-3/gost.so: undefined symbol: EVP_PKEY_base_id". We checked openssl the version 3.0.1, and 3.0.3, and 3.1.3 with the same engine. It work. In the openssl it fixed, but in the version >=3.0.3. Thanks ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: openssl 3.0.2-0ubuntu1.10 ProcVersionSignature: Ubuntu 6.2.0-34.34~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-34-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Oct 12 09:44:36 2023 InstallationDate: Installed on 2023-01-13 (271 days ago) InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1) SourcePackage: openssl UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2039142/+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
[Touch-packages] [Bug 2039142] Re: openssl v3.0.2 is not work with dynamic engine libengine-gost-openssl1.1
Hi, I have not been able to reproduce your issue. Since you did not provide the exact command you've used, I did a different test that relies on the engine. I did the following (lots of trial and error): * git clone https://github.com/gost-engine/engine * mkdir build * cd build * cmake -DOPENSSL_ENGINES_DIR=/usr/lib/x86_64-linux-gnu/engines-3/ .. * make install # install paths are pretty inconsistent and there's no way to uninstall but I'm going to throw away my test container * vim example.conf * change dynamic_path to "dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/gost.so" * OPENSSL_CONF=$(pwd)/example.conf openssl dgst -md_gost94 README.md I'm also a bit surprised by your error. The only recent commit I've found that touches EVP_PKEY_base_id reads the following: > if the newly loaded engine contains the symbol > EVP_PKEY_base_id, we know it is linked to 1.1.x openssl. > Abort loading this engine, as it will definitely crash. As far as I understand it, the only use for this symbol is to detect that there's a version mismatch. Are you sure you don't have both in your path? Moreover I didn't notice a change related to that between 3.0.2 and 3.0.3. Also, there is still libengine-gost-openssl1.1 in the archive for jammy (it's removed now). I tried with it too and it worked even though the gost.so is installed directly in / rather than in /usr/lib//engines . I would need a reproducer to investigate further. -- 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/2039142 Title: openssl v3.0.2 is not work with dynamic engine libengine-gost- openssl1.1 Status in openssl package in Ubuntu: New Bug description: Hello We use from a source code the gost engine for a check certificates chains. But openssl the version 3.0.2 is not correct load dynamic engines. openssl return error "40D7F65B7F7F:error:1280006A:DSO support routines:dlfcn_bind_func:could not bind to the requested symbol name:../crypto/dso/dso_dlfcn.c:188:symname(EVP_PKEY_base_id): /usr/lib/x86_64-linux-gnu/engines-3/gost.so: undefined symbol: EVP_PKEY_base_id". We checked openssl the version 3.0.1, and 3.0.3, and 3.1.3 with the same engine. It work. In the openssl it fixed, but in the version >=3.0.3. Thanks ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: openssl 3.0.2-0ubuntu1.10 ProcVersionSignature: Ubuntu 6.2.0-34.34~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-34-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Oct 12 09:44:36 2023 InstallationDate: Installed on 2023-01-13 (271 days ago) InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1) SourcePackage: openssl UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2039142/+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
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
** Tags removed: foundations-todo -- 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/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress 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] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. The issue has also been reported independently and with another engine (devcrypto). The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. Found module linux-vdso64.so.1 with build-id:
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
(did my mail answer from yesterday get eaten by launchpad?)
Here's an updated debdiff that:
- renames files using the lp- prefix,
- reworks the changelog to a more typical format:
* what (LP: #)
- ${file}
- adds DEP-3 to the patches
I've pushed an updated build on LP at
https://launchpad.net/~adrien-n/+archive/ubuntu/openssl-jammy-sru/+packages
It's still building unfortunately and I noticed typos in the changelog
which I corrected but didn't upload to the PPA due to how long it takes
to build. The differences are very minor (first level of the lsit in
d/changelog used - rather than *).
** Patch added: "openssl_3.0.2-0-ubuntu1.10-to-1.11.diff"
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+attachment/5707350/+files/openssl_3.0.2-0-ubuntu1.10-to-1.11.diff
--
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/2033422
Title:
openssl: backport to jammy "clear method store / query cache
confusion"
Status in openssl package in Ubuntu:
New
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.
This ( #2033422 ) is the "central" bug with the global information and
debdiff.
This SRU addresses four issues with Jammy's openssl version:
- http://pad.lv/1990216: Blowfish OFB/CFB decryption
- http://pad.lv/1994165: ignored SMIME signature errors
- http://pad.lv/2023545: imbca engine dumps core
- http://pad.lv/2033422: very high CPU usage for concurrent TLS connections
The SRU information has been added to the four bug reports and I am
attaching the debdiff here only for all four.
All the patches have been included in subsequent openssl 3.0.x
releases which in turn have been included in subsequent Ubuntu
releases. There has been no report of issues when updating to these
Ubuntu releases.
I have rebuilt the openssl versions and used abi-compliance-checker to
compare the ABIs of the libraries in jammy and the one for the SRU.
Both matched completely (FYI, mantic's matched completely too).
The patch related to blowfish presents an annoying situation: jammy's openssl
creates incompatible files and cannot read other files but fixing it will lead
to files created on jammy so far to become unreadable. Fortunately, blowfish is
long-deprecated and applications can be improved to handle this situation if
the need arises in practice.
This is stated in the SRU information in the bug and in d/changelog.
The current situation in Jammy could be a security issue but due to the
aforementioned deprecation, the low usage of blowfish and the fact that
upstream didn't consider this worthy of a security notice, we (this includes
the security team) chose not to pursue that path either.
I have also pushed the code to git (without any attempt to make it
git-ubuntu friendly).
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
sru
I asked Brian Murray about phasing speed and he concurs a slow roll-out is
probably better for openssl. There is a small uncertainty because a security
update could come before the phasing is over, effectively fast-forwarding the
SRU. Still, unless there is already a current pre-advisory, this is probably
better than a 10% phasing which is over after only a couple days anyway.
NB: at the moment openssl doesn't phase slowly so this needs to be
implemented.
[Impact]
Severely degraded performance for concurrent operations compared to openssl
1.1. The performance is so degraded that some workloads fail due to timeouts or
insufficient resources (noone magically has 5 times more machines). As a
consequence, a number of people use openssl 1.1 instead and do not get security
updates.
[Test plan]
Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
.
Using this, I get the following numbers on my laptop:
3.0.2:
real 2m5.567s
user 4m3.948s
sys 2m0.233s
this SRU:
real 0m23.966s
user 2m35.687s
sys 0m1.920s
As can be easily seen, the speed-up is massive: system time is divided
by 60 and overall wall clock time is roughly five times lower.
In http://pad.lv/2009544 , Rafael also shared his performance numbers
and they are relatable to these. He used slightly different versions
(upstreams rather than patched with cherry-picks) but at least one of
the version used does not include other performance change. He also
used different hardware and this performance issue seems to depend on
the number of CPUs available but also obtained a performance several
times better. Results on a given machine
[Touch-packages] [Bug 2037202] Re: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up
Thanks for the precision Marian. Dimitri, do you know if the "sleep 1" works in practice? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2037202 Title: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up Status in initramfs-tools package in Ubuntu: New Bug description: I'm not sure whether this is the correct package for this bug, please reassign if not. I'm booting the Ubuntu Mantic/23.10 desktop beta image via PXE in order to perform an unattended installation. The kernel command line looks like that: iso/casper/vmlinuz --- ip=dhcp netboot=nfs nfsroot=192.168.1.1:/export/ubuntu autoinstall ds=nocloud\;s= This has worked perfectly before. However, in 23.10, the kernel tries to intialize DHCP before a network link is up. I can see a few instances of messages like the following: dhcpcd-10.0.2 starting dev: loaded udev no interfaces have a carrier exiting due to oneshot dhcpcd exited Then, the kernel tries to mount NFS, even though neither an IP address nor even a link is available: connect: Network is unreachable NFS over TCP not available from 192.168.1.1 This is repeated for a while. In between, a message tells that now the link is up: [10.0002805] e1000e :00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx The NFS messages repeat for a while, until the system gives up and I'm dropped into a busybox prompt. Executing dhcpcd now correctly gets IP addresses, but I don't know how to continue the boot from there. The problem occurs on most physical machines that I tried, but not in VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2037202/+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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). The patch related to blowfish presents an annoying situation: jammy's openssl creates incompatible files and cannot read other files but fixing it will lead to files created on jammy so far to become unreadable. Fortunately, blowfish is long-deprecated and applications can be improved to handle this situation if the need arises in practice. This is stated in the SRU information in the bug and in d/changelog. The current situation in Jammy could be a security issue but due to the aforementioned deprecation, the low usage of blowfish and the fact that upstream didn't consider this worthy of a security notice, we (this includes the security team) chose not to pursue that path either. I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru + + I asked Brian Murray about phasing speed and he concurs a slow roll-out is probably better for openssl. There is a small uncertainty because a security update could come before the phasing is over, effectively fast-forwarding the SRU. Still, unless there is already a current pre-advisory, this is probably better than a 10% phasing which is over after only a couple days anyway. + NB: at the moment openssl doesn't phase slowly so this needs to be implemented. [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. In http://pad.lv/2009544 , Rafael also shared his performance numbers and they are relatable to these. He used slightly different versions (upstreams rather than patched with cherry-picks) but at least one of the version used does not include other performance change. He also used different hardware and this performance issue seems to depend on the number of CPUs available but also obtained a performance several times better. Results on a given machine vary also very little across runs (less than 2% variation on runs of size 10). They are also very similar on a Raspberry Pi 4 (8GB). The benchmark uses https://www.google.com/humans.txt which takes around 130ms to download on my machine but I modified the script to download something only 20ms away. Results are so close to the ones using humans.txt that they are within the error margin. This is consistent with the high-concurrency in the benchmark which both saturates CPU, and "hides" latencies that are relatively low. Finally, there are positive reports on github. Unfortunately they are not always completely targeted at these patches only and therefore I will not link directly to them but they have also been encouraging. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to these changes was reported on launchpad or upstream. However, it is possible that
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). The patch related to blowfish presents an annoying situation: jammy's openssl creates incompatible files and cannot read other files but fixing it will lead to files created on jammy so far to become unreadable. Fortunately, blowfish is long-deprecated and applications can be improved to handle this situation if the need arises in practice. This is stated in the SRU information in the bug and in d/changelog. The current situation in Jammy could be a security issue but due to the aforementioned deprecation, the low usage of blowfish and the fact that upstream didn't consider this worthy of a security notice, we (this includes the security team) chose not to pursue that path either. I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. + In http://pad.lv/2009544 , Rafael also shared his performance numbers + and they are relatable to these. He used slightly different versions + (upstreams rather than patched with cherry-picks) but at least one of + the version used does not include other performance change. He also used + different hardware and this performance issue seems to depend on the + number of CPUs available but also obtained a performance several times + better. Results on a given machine vary also very little across runs + (less than 2% variation on runs of size 10). They are also very similar + on a Raspberry Pi 4 (8GB). + + The benchmark uses https://www.google.com/humans.txt which takes around + 130ms to download on my machine but I modified the script to download + something only 20ms away. Results are so close to the ones using + humans.txt that they are within the error margin. This is consistent + with the high-concurrency in the benchmark which both saturates CPU, and + "hides" latencies that are relatively low. + + Finally, there are positive reports on github. Unfortunately they are + not always completely targeted at these patches only and therefore I + will not link directly to them but they have also been encouraging. + [Where problems could occur] The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to these changes was reported on launchpad or upstream. However, it is possible that there were more patch dependencies than these in either 3.0.3 or 3.0.4. In that case there could be problems. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - http://pad.lv/1990216: Blowfish OFB/CFB decryption - http://pad.lv/1994165: ignored SMIME signature errors - http://pad.lv/2023545: imbca engine dumps core - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). The patch related to blowfish presents an annoying situation: jammy's openssl creates incompatible files and cannot read other files but fixing it will lead to files created on jammy so far to become unreadable. Fortunately, blowfish is long-deprecated and applications can be improved to handle this situation if the need arises in practice. This is stated in the SRU information in the bug and in d/changelog. The current situation in Jammy could be a security issue but due to the aforementioned deprecation, the low usage of blowfish and the fact that upstream didn't consider this worthy of a security notice, we (this includes the security team) chose not to pursue that path either. I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: real 2m5.567s user 4m3.948s sys 2m0.233s this SRU: real 0m23.966s user 2m35.687s sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to these changes was reported on launchpad or upstream. + However, it is possible that there were more patch dependencies than + these in either 3.0.3 or 3.0.4. In that case there could be problems. + [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 *
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
** Description changed: === 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 #2033422 + The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. The issue has also been reported independently and with another engine (devcrypto). The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. Found module linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e Found module libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731 Found module ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08 Found module ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
** Description changed:
=== 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 #2033422
+ 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+wIABFla
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
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
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=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=04ef023920ab08fba214817523fba897527dfff0
===
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
** Description changed: === 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 #2033422 + The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Kinetic: Won't Fix 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] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - - #1990216: Blowfish OFB/CFB decryption - - #1994165: ignored SMIME signature errors - - #2023545: imbca engine dumps core - - #2033422: very high CPU usage for concurrent TLS connections + - http://pad.lv/1990216: Blowfish OFB/CFB decryption + - http://pad.lv/1994165: ignored SMIME signature errors + - http://pad.lv/2023545: imbca engine dumps core + - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). The patch related to blowfish presents an annoying situation: jammy's openssl creates incompatible files and cannot read other files but fixing it will lead to files created on jammy so far to become unreadable. Fortunately, blowfish is long-deprecated and applications can be improved to handle this situation if the need arises in practice. This is stated in the SRU information in the bug and in d/changelog. The current situation in Jammy could be a security issue but due to the aforementioned deprecation, the low usage of blowfish and the fact that upstream didn't consider this worthy of a security notice, we (this includes the security team) chose not to pursue that path either. I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks in #2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . Using this, I get the following numbers on my laptop: 3.0.2: - real 2m5.567s - user 4m3.948s - sys 2m0.233s + real 2m5.567s + user 4m3.948s + sys 2m0.233s this SRU: - real 0m23.966s - user 2m35.687s - sys 0m1.920s + real 0m23.966s + user 2m35.687s + sys 0m1.920s As can be easily seen, the speed-up is massive: system time is divided by 60 and overall wall clock time is roughly five times lower. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to these changes was reported on launchpad or upstream. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 *
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Meta] This bug is part of a series of four bugs for a single SRU. This ( #2033422 ) is the "central" bug with the global information and debdiff. This SRU addresses four issues with Jammy's openssl version: - #1990216: Blowfish OFB/CFB decryption - #1994165: ignored SMIME signature errors - #2023545: imbca engine dumps core - #2033422: very high CPU usage for concurrent TLS connections The SRU information has been added to the four bug reports and I am attaching the debdiff here only for all four. All the patches have been included in subsequent openssl 3.0.x releases which in turn have been included in subsequent Ubuntu releases. There has been no report of issues when updating to these Ubuntu releases. I have rebuilt the openssl versions and used abi-compliance-checker to compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). The patch related to blowfish presents an annoying situation: jammy's openssl creates incompatible files and cannot read other files but fixing it will lead to files created on jammy so far to become unreadable. Fortunately, blowfish is long-deprecated and applications can be improved to handle this situation if the need arises in practice. This is stated in the SRU information in the bug and in d/changelog. The current situation in Jammy could be a security issue but due to the aforementioned deprecation, the low usage of blowfish and the fact that upstream didn't consider this worthy of a security notice, we (this includes the security team) chose not to pursue that path either. I have also pushed the code to git (without any attempt to make it git- ubuntu friendly). https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- sru [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] - Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. + Rafael Lopez has shared a simple benchmarks in #2009544 with https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py . + Using this, I get the following numbers on my laptop: + + 3.0.2: + real 2m5.567s + user 4m3.948s + sys 2m0.233s + + this SRU: + real 0m23.966s + user 2m35.687s + sys 0m1.920s + + As can be easily seen, the speed-up is massive: system time is divided + by 60 and overall wall clock time is roughly five times lower. [Where problems could occur] - The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. + The change is spread over several patches which touch the internals of openssl. As such, the engine and provider functionality could be broken by these changes. Fortunately, in addition to upstream's code review, these patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue related to these changes was reported on launchpad or upstream. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 *
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
** Description changed: === 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 #2033422 [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Kinetic: Won't Fix 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 #2033422 [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
** Description changed: === 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 #2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. The issue has also been reported independently and with another engine (devcrypto). The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. Found module linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e Found module libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731 Found module ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08 Found module ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c Found module libc.so.6 with
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
** Description changed:
=== 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 #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+wIABFla
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
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
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=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=04ef023920ab08fba214817523fba897527dfff0
=== Original description ===
OpenSSL upstream implemented a fix for their issue #18359
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
Attaching debdiff for openssl from 3.0.2-0ubuntu1.10 to 3.0.2-0ubuntu1.11 ** Description changed: === 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 #2033422 + + This SRU addresses four issues with Jammy's openssl version: + - #1990216: Blowfish OFB/CFB decryption + - #1994165: ignored SMIME signature errors + - #2023545: imbca engine dumps core + - #2033422: very high CPU usage for concurrent TLS connections + + The SRU information has been added to the four bug reports and I am + attaching the debdiff here only for all four. + + All the patches have been included in subsequent openssl 3.0.x releases + which in turn have been included in subsequent Ubuntu releases. There + has been no report of issues when updating to these Ubuntu releases. + + I have rebuilt the openssl versions and used abi-compliance-checker to + compare the ABIs of the libraries in jammy and the one for the SRU. Both matched completely (FYI, mantic's matched completely too). + + The patch related to blowfish presents an annoying situation: jammy's + openssl creates incompatible files and cannot read other files but + fixing it will lead to files created on jammy so far to become unreadable. Fortunately, blowfish is long-deprecated and applications + can be improved to handle this situation if the need arises in practice. + This is stated in the SRU information in the bug and in d/changelog. + The current situation in Jammy could be a security issue but due to the aforementioned deprecation, the low usage of blowfish and the fact that upstream didn't consider this worthy of a security notice, we (this includes the security team) chose not to pursue that path either. + + I have also pushed the code to git (without any attempt to make it git- + ubuntu friendly). + + https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy- + sru [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0007-Add-method-store-cache-flush-and-method-removal-to-n.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === This is about SRU'ing to Jammy the patches at https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 . They're purely performance but their impact is large. They have been released as part of openssl 3.0.4 (they're among the first after 3.0.3) which has been included in Kinetic. ** Description changed: ** Description changed: === 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
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
** Description changed: === SRU information === [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. The issue has also been reported independently and with another engine (devcrypto). The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. + + [Patches] + The patches come directly from upstream and apply cleanly. + + https://github.com/openssl/openssl/issues/18578 + + * + https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- + sru-0001-Release-the-drbg-in-the-global-default-context- + befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. Found module linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e Found module libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731 Found module ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08 Found module ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c Found module libc.so.6 with build-id: 74250317950da91d3345f258cb2dd12d22c3f2e5 Found module libcrypto.so.3 with
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
** Description changed:
=== SRU information ===
[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+wIABFla
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
/5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
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 ).
+ [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=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=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?
**
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: === SRU information === [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. + [Patches] + The patches come directly from upstream and apply cleanly. + + https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 + + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0007-Add-method-store-cache-flush-and-method-removal-to-n.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + === Original description === This is about SRU'ing to Jammy the patches at https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 . They're purely performance but their impact is large. They have been released as part of openssl 3.0.4 (they're among the first after 3.0.3) which has been included in Kinetic. -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 *
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
** Description changed: === SRU information === [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 + + - https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + - https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` ** Description changed: === SRU information === [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 - - https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 - - https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 + * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
** Description changed: === SRU information === [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. + + [Patches] + The patches come directly from upstream and apply cleanly. + + https://github.com/openssl/openssl/pull/18876 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Kinetic: Won't Fix Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/pull/18876 === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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
[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"
** Description changed: + === SRU information === + + [Impact] + Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. + + [Test plan] + Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. + + [Where problems could occur] + The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. + + === Original description === + This is about SRU'ing to Jammy the patches at https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 . They're purely performance but their impact is large. They have been released as part of openssl 3.0.4 (they're among the first after 3.0.3) which has been included in Kinetic. -- 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/2033422 Title: openssl: backport to jammy "clear method store / query cache confusion" Status in openssl package in Ubuntu: New Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Impact] Severely degraded performance for concurrent operations compared to openssl 1.1. The performance is so degraded that some workloads fail due to timeouts or insufficient resources (noone magically has 5 times more machines). As a consequence, a number of people use openssl 1.1 instead and do not get security updates. [Test plan] Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at least as high. [Where problems could occur] The change is spread over several patches which touch the internals of openssl. Upstream has code review in place and the patches have first appeared in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago and we have not seen issues crop up. === Original description === This is about SRU'ing to Jammy the patches at https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 . They're purely performance but their impact is large. They have been released as part of openssl 3.0.4 (they're among the first after 3.0.3) which has been included in Kinetic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+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
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
** Description changed: + === SRU information === + + [Impact] + Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. + + [Test plan] + An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. + The issue has also been reported independently and with another engine (devcrypto). + The issue is fixed in openssl 3.0.8 which landed in lunar. + + [Where problems could occur] + I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. + + === Original description === + + openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem + -keyout __key.pem --subj '/CN=US' + ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 - 03ffae11c700: 4700bc0,0 - #03ffae11c704: b24f00a0ear%r10,%a0 - >03ffae11c708: 58102018l%r1,24(%r2) - 03ffae11c70c: ebaa002dsllg%r10,%r10,32 - 03ffae11c712: b24f00a1ear%r10,%a1 - 03ffae11c716: 5910a0d0c%r1,208(%r10) - 03ffae11c71a: a7840033brc8,03ffae11c780 + 03ffae11c700: 4700bc0,0 + #03ffae11c704: b24f00a0ear%r10,%a0 + >03ffae11c708: 58102018l%r1,24(%r2) + 03ffae11c70c: ebaa002dsllg%r10,%r10,32 + 03ffae11c712: b24f00a1ear%r10,%a1 + 03ffae11c716: 5910a0d0c%r1,208(%r10) + 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. -Found module linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e -Found module libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731 -
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
** Description changed: === SRU information === [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] - This issue is not very simple to reproduce because "penssl cms" cannot be used to do so. This has to be done with the openssl API instead. + This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Kinetic: Won't Fix Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "openssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
** Description changed:
=== SRU information ===
[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
+ 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
+ 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+wIABFla
+ /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
+ 8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
+ hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
+ m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
+ D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
+ ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
+ GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
+ AoBQAACjzq5WscRn+wIABFla
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
- /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
- 1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
+ /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
+ 8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
+ HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
+ jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
+ 2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
+ k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
+ /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
+ 1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
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]
- TBD
+ 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
+
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
** Description changed:
- 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
+ === SRU information ===
+
+ [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+wIABFla
+
+ 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
+ /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
+ 1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
+
+ 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]
+ TBD
+
+ === 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?
--
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 ===
[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
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
** Description changed: + === SRU information === + + [Impact] + S/MIME signature can fail silently + The commit by upstream propagates the return code of some functions rather than ignore it. + + [Test plan] + This issue is not very simple to reproduce because "penssl cms" cannot be used to do so. This has to be done with the openssl API instead. + At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. + + [Where problems could occur] + At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. + + === Original description === + https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 - Handle SMIME_crlf_copy return code - - Currently the SMIME_crlf_copy result is ignored in all usages. It does - return failure when memory allocation fails. - - This patch handles the SMIME_crlf_copy return code in all occurrences. - - Signed-off-by: Alon Bar-Lev - - Reviewed-by: Tomas Mraz - Reviewed-by: Paul Dale - Reviewed-by: Hugo Landau - (Merged from https://github.com/openssl/openssl/pull/18876) + Handle SMIME_crlf_copy return code + + Currently the SMIME_crlf_copy result is ignored in all usages. It does + return failure when memory allocation fails. + + This patch handles the SMIME_crlf_copy return code in all + occurrences. + + Signed-off-by: Alon Bar-Lev + + Reviewed-by: Tomas Mraz + Reviewed-by: Paul Dale + Reviewed-by: Hugo Landau + (Merged from https://github.com/openssl/openssl/pull/18876) ``` -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Kinetic: Won't Fix Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Impact] S/MIME signature can fail silently The commit by upstream propagates the return code of some functions rather than ignore it. [Test plan] This issue is not very simple to reproduce because "penssl cms" cannot be used to do so. This has to be done with the openssl API instead. At least the bug reportere here and the one on openssl's bug tracker have confirmed the patch solves the issue. Additionally, the bug reporter here has tested the PPA that contains the patche and validated it. Finally, I read through the patch attentively. [Where problems could occur] At this point it is unlikely an error would appear. The openssl bug tracker mentions nothing related to this patch which landed more than a year ago. The patch is simple and doesn't change the code logic. === Original description === https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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
[Touch-packages] [Bug 2037202] Re: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up
Should dhcp really be oneshot? I don't know what dhclient was doing (I guess it was dhclient before) but it sounds difficult to synchronize this properly. I imagine it's also possible to run the dhcp client in oneshot mode in a loop with maybe 3 iterations and "sleep 1" in between. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2037202 Title: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up Status in initramfs-tools package in Ubuntu: New Bug description: I'm not sure whether this is the correct package for this bug, please reassign if not. I'm booting the Ubuntu Mantic/23.10 desktop beta image via PXE in order to perform an unattended installation. The kernel command line looks like that: iso/casper/vmlinuz --- ip=dhcp netboot=nfs nfsroot=192.168.1.1:/export/ubuntu autoinstall ds=nocloud\;s= This has worked perfectly before. However, in 23.10, the kernel tries to intialize DHCP before a network link is up. I can see a few instances of messages like the following: dhcpcd-10.0.2 starting dev: loaded udev no interfaces have a carrier exiting due to oneshot dhcpcd exited Then, the kernel tries to mount NFS, even though neither an IP address nor even a link is available: connect: Network is unreachable NFS over TCP not available from 192.168.1.1 This is repeated for a while. In between, a message tells that now the link is up: [10.0002805] e1000e :00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx The NFS messages repeat for a while, until the system gives up and I'm dropped into a busybox prompt. Executing dhcpcd now correctly gets IP addresses, but I don't know how to continue the boot from there. The problem occurs on most physical machines that I tried, but not in VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2037202/+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
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
Thanks a lot for taking the time to test and provide feedback. I'll continue with the SRU process which should take a few more weeks (I'd say between two and four but that's a very rough guess). -- 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: 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
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
Thanks a lot for taking the time to test and provide feedback. -- 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/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Kinetic: Won't Fix Status in openssl source package in Lunar: Fix Released Bug description: https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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
