Your message dated Wed, 17 Aug 2022 22:56:02 -0700
with message-id <Yv3UcrPk/0Ffu/t...@homer.dodds.net>
and subject line Re: Bug#978600: Substantial increase in pseudo-Essential due
to libnsl2 and libtirpc3 (and dependencies)
has caused the Debian Bug report #978600,
regarding Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3
(and dependencies)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
978600: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978600
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libpam-modules
Version: 1.4.0-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org, debian-de...@lists.debian.org
The new pam 1.4.0 has switched pam_unix from libnsl.so.1 (in libc6) to
libnsl2 and libtirpc3, which brings those packages into the
pseudo-Essential set. This is a rather substantial increase in the
number of pseudo-Essential packages; it also pulls in libgssapi-krb5-2,
libkrb5-3, libtirpc-common, libk5crypto3, libkrb5support0, and
libkeyutils1. In addition, it adds a second dependency on libcom-err2,
which was otherwise only pulled in by e2fsprogs (Essential but generally
safely removable).
I realize it makes sense to migrate from the previous libc-provided
RPC/NIS support to the separate libraries. However, this seems likely to
make those libraries quite difficult to remove from pseudo-Essential in
the future. I'm reporting this issue as soon as I noticed it, in the
hopes that it might be possible to mitigate this before the the next
stable release, before it becomes further entrenched and migrations
become more challenging.
A few possible ideas for how to address this:
- Make pam_unix dlopen the necessary libraries, which (given sufficient
notice) would allow dropping the hard dependency. Considering that
libc6 already only Recommends the NSS modules for NIS, it seems
reasonable to follow suit here.
- Build pam_unix with and without NIS support, and make libpam-modules
Pre-Depends on a non-Essential "libpam-unix-nis | libpam-unix". (This
seems rather more invasive, but cleaner long-term.)
- Migrate libpam-modules itself towards dropping the Essential flag. PAM
no longer "fails open" in the absence of configuration or specified
modules, so this should be safe. A system without PAM still functions,
and just doesn't support PAM authentications/sessions/etc; this
doesn't seem any more unreasonable than making init non-Essential
(because chroots and some containers don't need it), or eventually
making login non-Essential (because systems without interactive
console login don't need it).
I'm happy to contribute towards any of these paths, or another path that
would avoid expanding the pseudo-Essential set.
--- End Message ---
--- Begin Message ---
Version: 1.4.0-13
This issue has been addressed by disabling NIS password change support,
which discussion on debian-devel established was not a feature of
significant interest.
On Mon, Dec 28, 2020 at 08:34:56PM -0800, Josh Triplett wrote:
> Package: libpam-modules
> Version: 1.4.0-1
> Severity: normal
> X-Debbugs-Cc: j...@joshtriplett.org, debian-de...@lists.debian.org
>
> The new pam 1.4.0 has switched pam_unix from libnsl.so.1 (in libc6) to
> libnsl2 and libtirpc3, which brings those packages into the
> pseudo-Essential set. This is a rather substantial increase in the
> number of pseudo-Essential packages; it also pulls in libgssapi-krb5-2,
> libkrb5-3, libtirpc-common, libk5crypto3, libkrb5support0, and
> libkeyutils1. In addition, it adds a second dependency on libcom-err2,
> which was otherwise only pulled in by e2fsprogs (Essential but generally
> safely removable).
>
> I realize it makes sense to migrate from the previous libc-provided
> RPC/NIS support to the separate libraries. However, this seems likely to
> make those libraries quite difficult to remove from pseudo-Essential in
> the future. I'm reporting this issue as soon as I noticed it, in the
> hopes that it might be possible to mitigate this before the the next
> stable release, before it becomes further entrenched and migrations
> become more challenging.
>
> A few possible ideas for how to address this:
>
> - Make pam_unix dlopen the necessary libraries, which (given sufficient
> notice) would allow dropping the hard dependency. Considering that
> libc6 already only Recommends the NSS modules for NIS, it seems
> reasonable to follow suit here.
> - Build pam_unix with and without NIS support, and make libpam-modules
> Pre-Depends on a non-Essential "libpam-unix-nis | libpam-unix". (This
> seems rather more invasive, but cleaner long-term.)
> - Migrate libpam-modules itself towards dropping the Essential flag. PAM
> no longer "fails open" in the absence of configuration or specified
> modules, so this should be safe. A system without PAM still functions,
> and just doesn't support PAM authentications/sessions/etc; this
> doesn't seem any more unreasonable than making init non-Essential
> (because chroots and some containers don't need it), or eventually
> making login non-Essential (because systems without interactive
> console login don't need it).
>
> I'm happy to contribute towards any of these paths, or another path that
> would avoid expanding the pseudo-Essential set.
>
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
--- End Message ---
