Bug#977360: libsasl2-modules-gssapi-mit: SCRAM is not a GSSAPI-MIT mechanism

2022-04-18 Thread Bastian Germann

You are right. I do not think that there was much thought put in on adding the 
mechanism,
as you can read in #628067.

I think, SCRAM should be moved to the libsasl2-modules package. Any comments on 
that?



Bug#977360: libsasl2-modules-gssapi-mit: SCRAM is not a GSSAPI-MIT mechanism

2020-12-14 Thread Rick van Rein
Package: libsasl2-modules-gssapi-mit
Version: 2.1.27+dfsg-1+deb10u1
Severity: important

Dear Maintainer,

The SCRAM mechanisms for SASL are useful as replacements of
deprecated DIGEST-MD5 mechanisms, but without this package
that often continues to be the default.  This is why it is
not good to package SCRAM as a separate add-on that also
depends on Kerberos infrastructure.

SCRAM is, in the end, a password mechanism and not at all
related to Kerberos infrastructure.

There is a relation that probably caused this; SCRAM uses
the same GS2 layer that is also used for GS2-KRB5.  This
layer however, is general.  GS2 is a compatibility layer
between GSSAPI and SASL, and GSSAPI is more general than
merely a carrier for Kerberos -- and so is GS2.

The package name is a misnomer at the very least, but the
tight bond between Kerberos and SCRAM is a mistake.

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Attempts to run SCRAM without also having Kerberos in place.
Specifically, as part of automated testing procedures in which
we wanted to get away from DIGEST-MD5 we installed this add-on
and found the system failing on account of absent Kerberos
tickets.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Running without this package removes the problem (and the
security by falling back on obsolete DIGEST-MD5).

   * What was the outcome of this action?

Running without this package removes the problem (and the
security by falling back on obsolete DIGEST-MD5).

   * What outcome did you expect instead?

Without a ticket in place, that Kerberos would not be
selected as a mechanism by the SASL client, while the
SCRAM mechanism would have been available.  One way
of achieving that would have been an installation of
a SCRAM package without necessary bond to Kerberos.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsasl2-modules-gssapi-mit depends on:
ii  libc6 2.28-10
ii  libcom-err2   1.44.5-1+deb10u3
ii  libgssapi-krb5-2  1.17-3+deb10u1
ii  libk5crypto3  1.17-3+deb10u1
ii  libkrb5-3 1.17-3+deb10u1
ii  libsasl2-modules  2.1.27+dfsg-1+deb10u1
ii  libssl1.1 1.1.1d-0+deb10u3

libsasl2-modules-gssapi-mit recommends no packages.

libsasl2-modules-gssapi-mit suggests no packages.

-- no debconf information