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.