Re: New PAM in experimental needs testing
On Sun, Aug 05, 2007 at 06:36:45PM +0100, Roger Leigh wrote:
> Several of the Debian-specific patches should probably be removed.
> For example, the @include (Debian-specific) syntax should be replaced
> by the include mechanism added by upstream; we should make this a
> release goal for Lenny IMO. Maintaining Debian-specific hacks imposes
> a real burden on the PAM maintainers--it took over 15 man hours to do
> the main re-diffing, and the same again to get it working, which is
> ridiculous and error-prone. We could easily be introducing
> Debian-specific security bugs by doing so. Some checks such as the
> obscure checks for pam_unix and chroot limits for pam_limits should be
> dropped (who uses this functionality)? The obsure checks appear to
> predate PAM, but should cracklib not be the replacement? This
> non-standard stuff should really be deprecated, obsoleted, then
> dropped. What do other people think about this?
Well, this is exactly the opposite of my intent, which is to review the
patches, clean them up and push them upstream for consideration. I think
the Debian include syntax is preferable to the syntax currently adopted
upstream; the pam_unix 'obscure' checks, and min/max password length
controls, are features not available elsewhere. I wouldn't be surprised if
the chroot "limits" patch was rejected by upstream, but I at least intend to
propose it before dropping it from Debian since it's been around for so
> One other note: upstream now default to enabling cracklib in pam_unix
> (in addition to pam_cracklib), which causes passwd to do all the extra
> checks cracklib does. This has been disabled for now after discussion
> with Jan, because it brings in quite a few dependencies into base, and
> may not be generally wanted.
That's correct, this is the reason that libpam-cracklib is its own package.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.