On Tue, 2015-03-24 at 12:51 -0500, Michael Catanzaro wrote:
the system is installed. It doesn't make sense for Anaconda to enforce a different policy than will be enforced after installation, so it follows that we should all use --minquality=1 and just have different pwquality.conf to adjust the strength of the passwords if need be. I think that should be acceptable for all products.
You're pointing out the same thing I was wondering about when I read about this kickstart mechanism: We don't want to configure password policies in two places - thats only going to lead to anaconda disagreeing with the installed system.
We also need to make sure that our solution is acceptable to the gnome-initial-setup developers, which currently uses pwquality to display password strength but allows setting any password. If they won't accept any form of password strength enforcement, then I would favor ripping pwquality out of the PAM stack to resolve the problem. (Perhaps that could move to a subpackage.) I suspect a very lenient pwquality.conf may be the only way to reach a compromise here.
I think the difference of opinion is only about the enforcement part. If pwquality gives us useful information about that quality of the password then we absolutely show that to the user and help her to come up with a better password.