** Description changed:
[ Impact ]
- * An explanation of the effects of the bug on users and
+ 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.
- * justification for backporting the fix to the stable release.
+ 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.
- * In addition, it is helpful, but not required, to include an
- explanation of how the upload fixes this bug.
+ 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 ]
- * detailed instructions how to reproduce the bug
+ * detailed instructions how to reproduce the bug
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package fixes
- the problem.
+ * these should allow someone who is not familiar with the affected
+ package to reproduce the bug and verify that the updated package fixes
+ the problem.
- * if other testing is appropriate to perform before landing this update,
- this should also be described here.
+ * if other testing is appropriate to perform before landing this update,
+ this should also be described here.
[ Where problems could occur ]
- * Think about what the upload changes in the software. Imagine the change is
- wrong or breaks something else: how would this show up?
+ 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.
- * It is assumed that any SRU candidate patch is well-tested before
- upload and has a low overall risk of regression, but it's important
- to make the effort to think about what ''could'' happen in the
- event of a regression.
+ The test plan tries to cover the above scenarios.
- * This must '''never''' be "None" or "Low", or entirely an argument as to why
- your upload is low risk.
-
- * This both shows the SRU team that the risks have been considered,
- and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
-
- * Anything else you think is useful to include
- * Anticipate questions from users, SRU, +1 maintenance, security teams and
the Technical Board
- * and address these questions in advance
+
+ 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.
** Description changed:
[ 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 ]
- * detailed instructions how to reproduce the bug
-
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package fixes
- the problem.
-
- * if other testing is appropriate to perform before landing this update,
- this should also be described here.
+ 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)
[ 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.
--
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:
In Progress
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)
[ 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
