Bug#983407: Pam: Multiple issues Affecting Upgrades
> "Paul" == Paul Gevers writes: Paul> Just to elaborate, that set is frozen because bits that Paul> influence a lot of builds can become difficult to manage if a Paul> bug sneaks in. So it's good to discuss here how much pam can Paul> influence the built artifacts. Hence, it's not so much we Paul> want to prevent it in bullseye, but it's potential impact for Paul> the release process is already in unstable. Nod. Having broken pam for everyone once, I'm very aware of that kind of issue. I certainly wouldn't change pam for non-important issues at this point. My concern would be that we might break things and impact development or buildds *or* that we might break upgrades. (Doc changes are of course fine--the standard freeze policy stuff). At one level, pam probably doesn't matter that much for buildds because most things don't involve authentication. And yet enough links against libpam that it can be a big deal if it fails. Also, if it fails to upgrade, it could create a mess that way. --Sam
Bug#983407: Pam: Multiple issues Affecting Upgrades
Hi Sam, On 23-02-2021 20:09, Sam Hartman wrote: > Ah, I thought essential as well as build-essential was frozen. > Pam is not technically essential but is pre-depends for several > essentials. Aha, I may have missed that in my list when generating the list: https://release.debian.org/bullseye/essential-and-build-essential.txt I'll update that list. Just to elaborate, that set is frozen because bits that influence a lot of builds can become difficult to manage if a bug sneaks in. So it's good to discuss here how much pam can influence the built artifacts. Hence, it's not so much we want to prevent it in bullseye, but it's potential impact for the release process is already in unstable. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#983407: Pam: Multiple issues Affecting Upgrades
> "Paul" == Paul Gevers writes: Paul> On 23-02-2021 19:17, Sam Hartman wrote: >> This is just a FYI, opened as a bug because you've expressed a Paul> If it's in time to migrate before March 12, there's nothing to Paul> unblock. We're still only in soft freeze and pam is not on Paul> our build-essentials list. Ah, I thought essential as well as build-essential was frozen. Pam is not technically essential but is pre-depends for several essentials. >> or I may want to ask for additional review before I'm ready to >> recommend inclusion in testing. Paul> Be aware that we're no PAM experts. At least, I have no clue. Nod, I was thinking of asking more broadly than debian-release if only because you are busy. Review will mostly be on the maintainer script and debconf side; the pam specific bits are not interesting. >> * 982530: removal of pam_tally Paul> Severity currently is "normal", sounds like that not correct? Paul> At least it means it's not on our radar. Definitely wrong. Wasn't sure whether it should be serious or grave. Admittedly leaving it as normal seems wrong. I have upgraded to serious. >> Plan is to detect the situation and scream in the preinst. Down >> side is that means new strings that need translation (debconf >> templates) Paul> And how about mentioning this in the release notes? Will do that too. >> * 982295: pam won't deal with upgrades without an init script Paul> "Only" severity important, again, do you think that is Paul> correct? Possibly. This one is important or serious. It's serious if there's some package that breaks badly that has actually removed its init script. I haven't dug around to prove that it's RC, and felt uncomfortable upgrading a bug in Steve's package (even though I'm an uploader) without proof.
Bug#983407: Pam: Multiple issues Affecting Upgrades
Control: tags -1 moreinfo Hi Sam On 23-02-2021 19:17, Sam Hartman wrote: > This is just a FYI, opened as a bug because you've expressed a > preference for that communication style. Ack. > I hope to have something in experimental or unstable by end of this > week. Depending on my confidence in the fixes, I may be ready for an > unblock at that point If it's in time to migrate before March 12, there's nothing to unblock. We're still only in soft freeze and pam is not on our build-essentials list. > or I may want to ask for additional review > before I'm ready to recommend inclusion in testing. Be aware that we're no PAM experts. At least, I have no clue. > * 982530: removal of pam_tally Severity currently is "normal", sounds like that not correct? At least it means it's not on our radar. > Plan is to detect the situation and scream in the preinst. > Down side is that means new strings that need translation (debconf templates) And how about mentioning this in the release notes? > * 982295: pam won't deal with upgrades without an init script "Only" severity important, again, do you think that is correct? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#983407: Pam: Multiple issues Affecting Upgrades
Package: release.debian.org Severity: normal X-Debbugs-Cc: vor...@debian.org Hi. I'm writing with my pam uploader hat on to give you a heads up about two issues that are kind of nasty and affect upgrades. This is just a FYI, opened as a bug because you've expressed a preference for that communication style. Feel free to close now; if this is still open when I have an unblock ready, I'll close and file the unblock. I hope to have something in experimental or unstable by end of this week. Depending on my confidence in the fixes, I may be ready for an unblock at that point, or I may want to ask for additional review before I'm ready to recommend inclusion in testing. * 982530: removal of pam_tally Up through buster, there were pam_tally and pam_tally2 modules available to provide lockout. These modules were not in the default configuration, but apparently various hardening guides turned them on. They were deprecated upstream, and we've chosen to remove them from bullseye. Unfortunately, if your pam config includes these modules, then probably you can't login until you boot with rescue media and fix the pam config. Moreover, while you probably get reasonable errors in the journal, you probably can't see that because you can't log in. Plan is to detect the situation and scream in the preinst. Down side is that means new strings that need translation (debconf templates) * 982295: pam won't deal with upgrades without an init script Pam restarts various services on upgrade (including buster to bullseye). The consequence of not restarting can be segfaults or failed pam authentications going forward. (libpam-modules gets out of sync with libpam0g and ether fails to dlopen or segfaults depending). The logic in libpam0g.postinst is init-script specific. Our current policy allows init scripts to be removed, and apparently various users and downstreams are removing init scripts even when the package still contains them. I'm testing a patch to use systemd facilities for doing restarts if booted with systemd as init. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
