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

[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

Bug#868760: Blocked by this bug

[Rick van Rein]

This bug is blocking me from developing software for Kerberos and
compiling it for Raspberry Pi (ARMHF) with Multiarch.  Can you please
fix it?

When I run
 apt-get install krb5-user:armhf
I get
 krb5-user:armhf : Depends: krb5-config:armhf but it is not installable
however, there is just
 rc  krb5-config 2.6all
which depends on
 bind9-host

Installing bind9-host:armhf manually does not help.


Note https://wiki.ubuntu.com/MultiarchSpec
which states

Multi-Arch: foreign
The package is not co-installable and should be allowed to satisfy the
dependencies of a package of another architecture than its own.

If a package is declared Multi-Arch: foreign, preference should be given
to a package for the native architecture if available; if it is not
available, the package manager may automatically install any available
package, regardless of architecture, or it may choose to make this an
option controlled by user configuration.

Thanks,
 -Rick

Bug#510695: type in included config file for cman initscript

[Rick van Rein]

Package: cman
Version: 2.20081102-1
Severity: normal

The file /etc/init.d/cman contains an include statement for an options
file in /etc/defaults/cman -- but I found /etc/default/cman on mine.
I suspect this is a type in the initscript.

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i586)

Kernel: Linux 2.6.26-1-486
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cman depends on:
ii  debconf [debconf-2.0]  1.5.24Debian configuration management sy
ii  libc6  2.7-16GNU C Library: Shared libraries
ii  libcman2   2.20081102-1  Red Hat cluster suite - cluster ma
ii  libdlm22.20081102-1  Red Hat cluster suite - distribute
ii  libnet-snmp-perl   5.2.0-1   Script SNMP connections
ii  libnet-telnet-perl 3.03-3Script telnetable connections
ii  libnss3-1d 3.12.0-5  Network Security Service libraries
ii  libopenais20.83-1Standards-based cluster framework 
ii  libvirt0   0.4.6-10  library for interfacing with diffe
ii  libxml22.6.32.dfsg-5 GNOME XML library
ii  openais0.83-1Standards-based cluster framework 
ii  python 2.5.2-3   An interactive high-level object-o
ii  python-pexpect 2.1-1 Python module for automating inter
ii  sg3-utils  1.24-2Utilities for working with generic

cman recommends no packages.

cman suggests no packages.

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org