On Thu, Jan 29, 2015 at 3:18 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> 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.html >> >> 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.html 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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
