Hello,
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.
Yeah, I generally agree that anaconda’s policy and installed-system pwquality.conf should
be the same. Whether that ends up as anaconda allowing kickstart (and products) to
specify pwquality.conf, and obeying the configuration in there, or having pwpolicy also
edit pwquality.conf, is not hugely important to me; I would slightly favor keeping the
policy in the pwquality package, though.
<snip>
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.
That doesn’t make sense to me; if pwquality.conf is configured to be strict, _everything_
on the system should enforce that. Individual upstreams refusing to be strict should be
handled in Fedora by patching the software to implement distribution-wide consistency. A
product wanting to consistently not enforce strict policy rules should ship with a weak
pwquality.conf, still allowing administrators to harden the system, instead of ripping
pam_pwquality, or worse, individual instances of code, out and making enforcement more
difficult or impossible.
(It might be worth considering whether pwquality should be configurable to set the
enforcement level and the UI warning level separately. I’m not sure.)
Mirek