On Fri, Mar 6, 2015 at 2:00 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
> 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.
It will, Some of them will simply change it manually, with a manually
run 'passwd' command, or by publishing an already encrypted password
of arbitrary simplicity with a system management tool or shell script
as part of pickstart '%post' process if they know how. If the page had
a pointer
I'll point out two old documents that point out some of the problems
with this "let me outsmart people and force my concepts on them in
hardcoded software" approach. The first is an old XKCD aobut password
strength, pointing out just how silly many modern password checkers
are:
http://xkcd.com/936/
The other is Eric Raymond's "Luxury of Ignorance" essay, about why so
many open source interfaces are so horrible.
http://www.catb.org/esr/writings/cups-horror.html
In this case, anaconda enforcing a confusing and unclear password
strength algorithm with no visible information aoubt how a password is
judged 'strong enough would violate Eric's guidelines 1, 2, 3, 4, and
6. It also violates one of my guidelines that he added to that recipe,
the one about "Are there settings you can do from the command line or
hand-editing config files that cannot be done from the GUI?"
> * 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
How very sensible!
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
