>>>>> "Martin" == Martin Schurz <debian-b...@drachen-server.de> writes:
Hi. I apologize for taking a while to come up to speed on this and for a couple of false starts. It's been a while since pam has been a major focus of mine, but I offered to help Steve out so I'm coming back up to speed. I agree that we cannot comment out modules and apologize for not seeing the issues sooner. I think your second approach of looking into pam-configs, disabling anything that uses pam_tally and then checking /etc/pam.d would be most correct. Unfortunately I'm uncomfortable with our (or at least my) ability to get all the corner cases right this deep into the freeze. I'm currently thinking it would be good to just accept something like your first patch, although I'm open to exploring your second approach. Do you think it would be safe for me to change it to look in /var/lib/pam rather than /usr/share/pam-configs for pam_tally? I don't see a need to break the upgrade on a disabled module. I agree the /etc/pam.d check is still important. If we were going to do the second approach I think the steps involved might look like: * Check /var/lib/pam to see if any of the currently active profiles include pam_tally; if so disable them * modify pam-auth-update to never enable a profile including pam_tally * Do the /etc/pam.d check. Rationale here is that there's no reason to break the upgrade if a user has a pam_tally module already disabled nor to display a warning if the module is already disabled. But unless we actually remove the file from /usr/share/pam-configs, pam-auth-update will let a user enable it again.
signature.asc
Description: PGP signature
