On Fri, 6 Mar 2015 10:52:34 -0500 David Cantrell <dcantrell@xxxxxxxxxx> 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
Attachment:
pgpfkGKtDGRbj.pgp
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
