On Thu, Jan 29, 2015 at 3:18 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Thu, 2015-01-29 at 15:09 -0700, Chris Murphy wrote:
> On Thu, Jan 29, 2015 at 2:23 PM, Adam Williamson <
> adamwill(a)fedoraproject.org> wrote:
> > Seriously. Stop this. I have already asked people to stop
> > assigning negative motivations to others without due cause. This
> > is not being excellent to each other.
>
> "Your user password for your computer is arbitrarily unacceptable to
> the Fedora Project" is not being excellent either.
Come on, that's sophistry. You can't interpret code as a personal
insult.
Sure I can. Code is copyrightable language owned by the author if not
in property certainly in the consequences, just like any form of
written communication. I don't actually know the motives of the
Anaconda team, I'm only observing patterns that I think have lead and
continue to lead to questionable outcomes.
The last time this happened Anaconda only considered (questionable)
usability aspects without considering security aspects - that's what
the blow up on devel@ entailed; and this time Anaconda considers the
(questionable) security aspects without considering the usability
aspects.
(It's not 'arbitrary', anyway. It's using a well-known and widely-used
password quality library.)
The decision to enforce is what's arbitrary, not the tool being used
to grade the password. If a password library library that arbitrarily
pass/fails passwords, that would at least be funny.
> > The anaconda-devel-list discussion couldn't really be
clearer
> > about the relationship to the Change proposal - the whole thread
> > was kicked off by the Change owner:
> >
> >
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00026...
>
> That change proposal was rejected, so how is it that one of its
> proposed changes has managed to make it through to the installer
> barely two weeks later?
It's not actually something that is part of the Change's scope, but an
alternative way to try and achieve the same goal: the overall thought
process was "well, what the Change proposer really wants is to reduce
the likelihood of compromise via password access to the root account,
but no-one was particularly keen on the approach he proposed, so one
different way to do it is to improve the strength of the root
password". As bcl's mail explicitly says:
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00030...
That's not the point at all, which is, is it correct policy to
activate a sub-change in a rejected change proposal? And is it prudent
to dig heels in when there's been more negative feedback on that
change presented on anaconda-devel@ and test@ than positive? I can't
even find positive feedback except from the original change owner.
> The substantive discussion on devel@ was centered on the sshd
> portion, not changes to the installer enabling password quality
> enforcement. That happened on anaconda-devel@ which most Fedora
> users don't even monitor let alone participate. The main notice of
> this change actually occurring happened for the first time in test@
> which arguably most users also don't monitor.
If someone's interested in Fedora development, they need to read the
Fedora development mailing lists. *Any* code change is presumably of
interest to someone, or it wouldn't be done in the first place; this
is not a reason for us to go mailing users@ every time someone commits
to anaconda.
I'm suggesting instead of being presented only on test@, it should
also have been presented on devel@.
You can argue that the change is significant enough to be a Change,
I
guess, though personally I don't think it really is, unless it affects
kickstart installs (in which case people would be surprised at their
kickstarts suddenly not working right any more - but I don't think it
does). It's a bit hard to argue about, though, since one of the things
the Change process appears to be missing is an actual definition of
what should be considered to constitute a 'Change', exactly. It's thus
impossible to declare conclusively that X or Y *must* be a Change,
unless FESCo has stated it or something. You can suggest that it
should be, but it's impossible to make a completely definitive
declaration since there's literally no basis on which you could do
that outside of a formal FESCo vote or something.
https://fedoraproject.org/wiki/Changes/Policy
I was thinking of this one
http://fedoraproject.org/wiki/Features/Policy/Definitions and I think
certainly 1, and probably 5 apply, and though ill-conceived 3 could
apply too seeing as thus far it's only Fedora going down this absurd
road of negative efficacy.
--
Chris Murphy