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. > > > > > > 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? -- David Cantrell <dcantrell@xxxxxxxxxx> Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
