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. _______________________________________________ kde mailing list kde@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
