The verification of the Stable Release Update for cyrus-sasl2 has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1988730 Title: package libsasl2-modules provides only unsafe SASL bind mechanims Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in cyrus-sasl2 source package in Jammy: Fix Released Status in cyrus-sasl2 package in Debian: Fix Released Bug description: [ Impact ] The SASL SCRAM mechanism is incorrectly part of the libsasl2-modules- gssapi-mit package. It has nothing to do with MIT or GSSAPI, and should be in libsasl2-modules. Normally this would just be an annoyance, but it just so happens that this also prevents to have the SCRAM mechanism coexist with the GSSAPI Heimdal one, because libsasl2-modules-gssapi-{mit,heimdal} conflict with each other. This change is moving a file from one package to another, so appropriate breaks/replaces changes have to be made. This move follows case #10 from the package transition table[1]. [ Test Plan ] This test plan revolves around dependency checking and upgrades, to make sure we don't: - have conflicting files which would break an upgrade - have no loss of functionality after an upgrade (since a plugin moved between packages) a) SCRAM remains installed # Install the package that provides SCRAM in jammy $ sudo apt install libsasl2-modules-gssapi-mit # Confirm mechanism is there and belongs to libsasl2-modules-gssapi- mit: $ ll /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 lrwxrwxrwx 1 root root 18 Aug 16 20:08 /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 -> libscram.so.2.0.25 $ dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 libsasl2-modules-gssapi-mit:amd64: /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 # list installed sasl2 packages: $ dpkg -l | grep -E "^ii.*sasl2" | awk '{print $2,$3}' libsasl2-2:amd64 2.1.27+dfsg2-3ubuntu1.1 libsasl2-modules:amd64 2.1.27+dfsg2-3ubuntu1.1 libsasl2-modules-db:amd64 2.1.27+dfsg2-3ubuntu1.1 libsasl2-modules-gssapi-mit:amd64 2.1.27+dfsg2-3ubuntu1.1 # dist-upgrade or install the new sasl2 packages from proposed # Confirm the same packages are installed as before the upgrade, just at their newer versions: libsasl2-2:amd64 2.1.27+dfsg2-3ubuntu1.2 libsasl2-modules:amd64 2.1.27+dfsg2-3ubuntu1.2 libsasl2-modules-db:amd64 2.1.27+dfsg2-3ubuntu1.2 libsasl2-modules-gssapi-mit:amd64 2.1.27+dfsg2-3ubuntu1.2 # Confirm the scram mechanism is still there, as before: $ ll /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 lrwxrwxrwx 1 root root 18 Aug 16 20:08 /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 -> libscram.so.2.0.25 # But now it belongs to the libsasl2-modules package: $ dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 libsasl2-modules:amd64: /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 b) Following (a), perform a release-upgrade to kinetic, and confirm that the same sasl2 packages remain installed, but now at the kinetic version: $ dpkg -l | grep -E "^ii.*sasl2" | awk '{print $2,$3}' libsasl2-2:amd64 2.1.28+dfsg-6ubuntu2 libsasl2-modules:amd64 2.1.28+dfsg-6ubuntu2 libsasl2-modules-db:amd64 2.1.28+dfsg-6ubuntu2 libsasl2-modules-gssapi-mit:amd64 2.1.28+dfsg-6ubuntu2 And that the scram mechanism is there, and still belongs to the libsasl2-modules package: $ ll /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 lrwxrwxrwx 1 root root 18 Aug 16 20:08 /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 -> libscram.so.2.0.25 $ dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 libsasl2-modules:amd64: /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 c) A jammy system WITHOUT the SCRAM mechanism available (i.e., libsasl2-modules-gssapi-mit is NOT installed), will get SCRAM available after the upgrade, but without installing any new package. # Start with these sasl2 packages installed on jammy: libsasl2-2:amd64 2.1.27+dfsg2-3ubuntu1.1 libsasl2-modules:amd64 2.1.27+dfsg2-3ubuntu1.1 libsasl2-modules-db:amd64 2.1.27+dfsg2-3ubuntu1.1 # Confirm SCRAM is not installed: $ ll /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 ls: cannot access '/usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2': No such file or directory # Upgrade to the packages in proposed # Confirm no new sasl2 packages were installed: $ dpkg -l | grep -E "^ii.*sasl2" | awk '{print $2,$3}' libsasl2-2:amd64 2.1.27+dfsg2-3ubuntu1.2 libsasl2-modules:amd64 2.1.27+dfsg2-3ubuntu1.2 libsasl2-modules-db:amd64 2.1.27+dfsg2-3ubuntu1.2 # Verify that SCRAM is now available, and part of the libsasl2-modules package: $ ll /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 lrwxrwxrwx 1 root root 18 Aug 16 20:08 /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 -> libscram.so.2.0.25 $ dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 libsasl2-modules:amd64: /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 # Perform a release upgrade to kinetic, and confirm that no new sasl2 package is installed, and that the SCRAM mechanism remains available as before, belonging to the libsasl2-modules package. d) It's now possible to have SCRAM and gssapi heimdal mechanisms installed at the same time # On jammy, install libsasl2-modules-gssapi-mit so that you have SCRAM available: $ sudo apt install libsasl2-modules-gssapi-mit # Confirm SCRAM is available and part of the libsasl2-modules-gssapi- mit package: $ ll /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 lrwxrwxrwx 1 root root 18 Feb 22 2022 /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 -> libscram.so.2.0.25 $ dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 libsasl2-modules-gssapi-mit:amd64: /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 # If you try to install libsasl2-modules-gssapi-heimdal, you will lose the SCRAM mechanism because libsasl2-modules-gssapi-mit will be removed: $ sudo apt install libsasl2-modules-gssapi-heimdal (...) The following packages will be REMOVED: libsasl2-modules-gssapi-mit (...) $ dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 # IF, however, the above is attempted with the sasl2 packages from proposed available, then, even though libsasl2-modules-gssapi-mit is still removed, libsasl2-modules will be upgraded, and that will include the SCRAM mechanism: $ sudo apt install libsasl2-modules-gssapi-heimdal (...) The following packages will be REMOVED: libsasl2-modules-gssapi-mit (...) The following packages will be upgraded: libsasl2-modules # And in the end we have libsasl2-modules and libsasl2-modules-gssapi- heimdal installed, and SCRAM available: $ dpkg -l | grep sasl2 | awk '{print $2,$3}' libsasl2-2:amd64 2.1.27+dfsg2-3ubuntu1.1 libsasl2-modules:amd64 2.1.27+dfsg2-3ubuntu1.2 libsasl2-modules-db:amd64 2.1.27+dfsg2-3ubuntu1.1 libsasl2-modules-gssapi-heimdal:amd64 2.1.27+dfsg2-3ubuntu1.2 $ dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 libsasl2-modules:amd64: /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 # A release upgrade to kinetic must not change this situation, besides the versions of the packages. $ dpkg -l | grep sasl2 | awk '{print $2,$3}' libsasl2-2:amd64 2.1.28+dfsg-6ubuntu2 libsasl2-modules:amd64 2.1.28+dfsg-6ubuntu2 libsasl2-modules-db:amd64 2.1.28+dfsg-6ubuntu2 libsasl2-modules-gssapi-heimdal:amd64 2.1.28+dfsg-6ubuntu2 $ dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 libsasl2-modules:amd64: /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 [ Where problems could occur ] Since this change is moving a file from one package to the other, the problems that could occur will most likely be related to dependencies, and failures to install the packages because of file conflicts. Another possibility is problems during release upgrades, also related to conflicting files. Finally, another possible issue would be users who had certain SASL mechanisms installed before, be without them after the upgrade. The test plan tries to cover the above scenarios. [ Other Info ] This change comes from debian's 2.1.28+dfsg-4[2] upload, and is applied in kinetic and later. 1. https://wiki.debian.org/PackageTransition 2. https://salsa.debian.org/debian/cyrus-sasl2/-/commit/510c86097b7259f0033150c5a66115028736c157 [Original Description] Current Cyrus libsasl2 packaging (Ubuntu Jammy) distributes SASL bind mechanims into different packages. Plained and shared secret mechanisms are provided by package libsasl2-modules: /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2 /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2.0.25 /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2 /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2.0.25 /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2 /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25 /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2 /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2.0.25 /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2 /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2.0.25 /usr/lib/x86_64-linux-gnu/sasl2/libplain.so /usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2 /usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2.0.25 The "safest" mechanism in this list is DIGEST-MD5, which is marked as obsolete by IANA and regarded as unsafe by IETF. Current safest standard mechanisms are SCRAM based (RFC7677). All SCRAM family SASL mechanisms of Cyrus SASL are provided by Ubuntu package libsasl2-modules-gssapi-mit: /usr/lib/x86_64-linux-gnu/sasl2/libscram.so /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2 /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2.0.25 But the focus of this package is GSSAPI and GS2 SASL mechanism, which have nothing to do with SCRAM. In addition, this package conflicts with package libsasl2-modules-gssapi-heimdal. System administrators have to choose one package for support of GSSAPI or GSS-SPEGNO. If they prefer Heimdal there is no safe SASL shared secret mechanism available anymore on the server/workstation. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1988730/+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
