FESCO request to revert password confirmation change in F22

[Kevin Fenzi]

On Fri, 6 Mar 2015 10:52:34 -0500
David Cantrell <dcantrell at redhat.com> wrote:

> From what I'm reading in the meeting logs and the ticket comments, it
> appears the revert decision is basically a temporary solution and a
> more formal security policy will be discussed later.  We had
> technical arguments in favor of the change originally, but I have yet
> to see technical arguments against the change come together in any
> sort of concrete policy.

I think there were technical arguments, but they were hard to find in a
bunch of heated rhetoric in many cases. 

From my view: 

* Making this change in isolation now and then having to change it
  again to match a policy seems like a waste. If we revert enough of it
  now so we have time to make a policy we can just change it hopefully
  once. 

* The workstation folks think this change could drive away some of
  their potential users for not much gain. In their case, sshd is not
  enabled/running and additional security for a device that sits in
  your home isn't worth the additional complexity. 

* There's lots of questions around libpwquality and how well it works
  and what values it should be set at when. 

* There's lots of UI questions. Currently anaconda says "That password
  is bad" but it doesn't say why, or how to choose a good one, leading
  to some folks getting frustrated because they don't know the
  rules,etc. 

> I wish a formal distribution and/or per-variant security policy would
> come from FESCo (or a committee directed by FESCo) so we could
> resolve the concerns now and going forward.  I don't see the revert
> decision as being a good step in that direction, only because there
> was really no technical discussion or reasoning around it.

I'd LOVE a security policy to give you, but there's pretty much no way
we could have such a policy before F22 Alpha, so I think it's
reasonable to ask for a (partial) revert so we can try and gather time
and people and come up with something for F23. 

> Without an official policy on the matter and only a temporary
> solution for now, upstream won't be changing.  Fedora will need to
> carry this deviation as a patch in package git for F-22.

ok.

> > FESCO is prepared to work with anaconda and other stakeholders to
> > define security models for the various Fedora products.  By
> > clarifying our needs we hope to avoid this kind of contention in
> > the future.
> 
> The discussion for this might as well start now -or- at least early
> enough so it's not too late for F-23.

Absolutely it should. 

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150306/8827d57a/attachment.sig>