On Aug 4, 2005, at 6:18 PM, Jeremy Huntwork wrote:
Randy McMurchy wrote: Are there any disadvantages to including it in the LFS book?
There's at least one -- it's extra junk that gets in the way if you use any other library that provide password complexity checking.
After fighting to make cracklib compile and install for the last several years I replaced with it passwdqc (http://www.openwall.com/ passwdqc/). passwdqc requires PAM, and I'm not suggesting that we use it in place of cracklib, but cracklib is clearly not the only solution to this problem.
Another issue is that cracklib only helps you enforce whatever password policies cracklib likes. So if your password complexity policy doesn't match the one that cracklib enforces it's again just extra junk that gets in the way.
There's no mandate for LFS to be highly secure, and there are many things are not included (like SELinux utilities) but are required to meet such a goal. Frankly I don't see how cracklib is any different than PAM; they are both enhancements to a the basic password-based authentication system. I don't think either should be in LFS.
(It could be argued that shadow shouldn't be in LFS either, but I'm not aware of any other package that provides similar functionality, and shadow provides utilities to easily enable/disable it after installation)
Zach
smime.p7s
Description: S/MIME cryptographic signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
