(Please send mails to -submitter so I can actually see them, I'm the originator of this bug but I'm not subscribed to debian-boot) Joey, the cracklib2 library, IIRC, does not check for password robustness (i.e. size, use of characters, etc.) but, actually, tries to crack it using its dictionary. This prevents people from entering, for example 'debian' or 'debian123', as a password. Including it in d-i (as I suggested) would mean providing a dictionary for cracklib's (in installed systems it is available at /var/cache/cracklib/ and generated from from the local dictionaries being installed) which could be rather large: 820K in my local filesystem based on the 1,7M dictionary files I have installed (including spanish and english words) The libpam-passwdqc module, however, when stacked in /etc/pam.d/passwd, will do both the cracklib2 checks *and* checks for password robustness (minimum length, character sets in the password, etc). If we want to go that way I suggest we do what Owl's installer does [1]: - have PAM be configured to use libpam-passwdqc per default in any Debian system - have d-i install some common dictionaries, libpam-passwdqc and cracklib2 at the target system (that way Cracklib's dictionary will be generated there) - chroot to it and use PAM to set the root/user password (see pam_root_password [2]) - let PAM tell us if the password is valid or not. This could be done *in*addition* to some simple checks done in the installer itself, as I suggested initially and Masami Ichikawa implemented, as long as the checks done in d-i are consistent with libpam-passwdqc's configuration. This has the advantage that password checking would be a standard setup in any Debian system, regardless of whether the password is set on d-i or it's changed later. And would actually apply to all users (not only those configured through the d-i). It has the disadvantadge that is a major change that implies changes in other packages (PAM's default configuration) and significant coding (although this could be simplified if reusing Owl's code [3], which is already available) Another (different way) that could be implemented as an alternative would be to: - have d-i provide the cracklib-runtime + libcracklib2 + a proper (pregenerated) dictionary (note the size increase, as described above) - do some basic password checks within d-i (with the patch provided in this bug) - use the 'crack_testlib' binary to run a test on the password and let the user know if the password is based on a dictionary password. That would be easier to code and has the advantage that no other changes are needed (to PAM) but it has the disadvantages that the d-i size increases (which is an issue currently) and is also duplicating code (as the password checking code is already present in libpam-passwdqc, which we are not using in this case) Hope that helps clarify stuff, Javier [1] http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/owl-setup/setup/root_passwd_settle.cpp?rev=1.3;content-type=text%2Fx-cvsweb-markup [2] http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/owl-setup/setup/pam_root_passwd.cpp?rev=1.2;content-type=text%2Fx-cvsweb-markup [3] The .spec file claims It's BSD-licensed, but it would be nice to ask Solar Designer to add proper licenses to the headers of all the files in there, to avoid any licensing confusion with it.
Attachment:
signature.asc
Description: Digital signature