Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-- 
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test





[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux