On Thu, Feb 05, 2015 at 10:47:44AM -0500, David Cantrell wrote: > On Thu, Feb 05, 2015 at 09:53:30AM +0100, Matthias Clasen wrote: > > On Mon, 2015-02-02 at 18:38 -0500, David Cantrell wrote: > > > On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote: > > > > On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote: > > > > > > > > > I think the main point is the one nirik made; I don't think the devs > > > > > agree with your assessment of how significant this is. It's a minor > > > > > inconvenience; you just have to come up with a password that passes > > > > > the check, or use a kickstart. So I don't think they agree that it > > > > > needs a full-blown security audit and FESCo review or whatever, > > > > > because they don't think it's really that huge of a change in > > > > > behaviour. > > > > > > > > Having to come up with a password that passes the check is not 'a minor > > > > inconvenience'. Given how capricious libpwquality is about scoring > > > > (there have been some examples in this thread, there are more in > > > > gnome-initial-setup bugs), it is next to impossible. Next to impossible? Really? I've find it easy to come up with passwords that work. We even report libpwquality's reason for any failures. > > > > This discussion has been pretty heated, but I agree with there being > > > > some aspect of 'collective punishment' here: just because _some_ systems > > > > get installed with sshd enabled, all users who install the Workstation > > > > have to spend a couple of frustrating minutes trying to find a password > > > > that gets them past this hurdle. > > > > > > > > If this change stays, I anticipate the Workstation WG asking for a way > > > > to the workstation installer not enforce this. I know the anaconda folks > > > > are not eager to add variations like this, but that is exactly what we > > > > need: If you want to enforce product-specific policy in the installer, > > > > it needs to be a product-specific installer. > > > > > > You're assuming before asking. With the structure of the installer now, we > > > can look at changes like taking the password aspect and making it > > > product-specific controllable by a number of different methods. Our > > > historic aim to end variant specifics in the installer was because the old > > > code (and variants) lacked a way to assign owners to those product > > > specifics, which meant that requests of the installer to be product specific > > > meant we were asked to be the owners of those specifics. > > > > Let me ask now, then: can we make the change to reject 'weak' passwords > > specific to only those products that enable sshd by default, please ? > > [adding anaconda-devel-list to CC] > > >From a technical standpoint, I see this being possible. Conditionalize it > on sshd being enabled or not. That's not really variant-specific and just a > system condition we could work around. > > I'm putting this on anaconda-devel-list for further discussion. bcl, > others? What are your thoughts on this request? I don't think we should make it act differently. While the change request for sshd setup was the initial reason I wrote the changes, I think that ALL passwords on the system need to be strong these days. I don't find any of the arguments against the change to be compelling. The most valid one is repeated installs of throw-away VMs, and I addressed that in my original post. Just make up a password that passes and write it down. If we do make this conditional, either based on sshd being active, or per-product then where do we stop? Most decisions the installer makes about the system could be called 'enforcing', so do we now have to have a vote on every change? Passwords are the gateway to people's private data. We should be encouraging them to choose stronger passwords and we should remember that we're not the only people running Fedora. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
