On Thu, Feb 26, 2015 at 11:37 AM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > > On 26 February 2015 at 11:25, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> >> >> So for any of you who don't like verbal fist fights? You're not >> serious. You don't take these changes seriously enough if you're not >> willing to argue vehemently, angrily, in favor of them. You have to >> demonstrate to your fellow primates that this is serious business and >> we have no alternatives right now than to shift the burden to the >> user. If you can't do that and stick with it, give it up. Instead, >> consider the alternatives that don't require user cooperation. >> > > Sorry, but I find any call for violence even verbal violence to be > counter-productive. I may agree with some of your points but I will not be > party to reenacting the Dawn of Time from 2001. It's strictly a metaphor. If you're not willing to strenuously argue your points, then you're acknowledging your position isn't really worth it *to you*, and your fellow person will see that you're not that committed and that incentivizes them to remain unconvinced. That's the point. I'm definitely not recommending this approach because I think by now I've argued the trust capital simply isn't there. This exact same thing happened almost two years ago, it turned into a devel@ sh|tshow, and it was at best distressing and disruptive. As a result: a. Distrust in Anaconda when it comes to any change being well vetted in advance, but especially on the matter of security and passwords. b. Distrust in Fedora process that this was possible: reminder, the change happened silently, it abruptly appeared in Fedora 18 Beta TC2. c. The ensuing uproar successfully resulted in a reversion. d. There was no contrition or acknowledgement how the process could be improved to have avoided the kerfuffle in the first place. Now, if there's any possible way to Do This Wrong™ it would be do make a password policy change silently without consulting anyone again. And it has less to do with the merit or scope of the change, but rather on trying to rebuild trust. The sociologically right thing to do would be to be contrite, to try and rebuild trust, by voluntarily going through the change process, and vetting this idea with security folks. Yet none of that was done, instead we have a repeat of history, and thus more damaged trust. And it's a peripherally damaging thing, when trust is lost people don't just lose it on a single target, it has ripple effects and the consequences are broad in scope. So I pretty much guarantee (and hey if I'm wrong and have egg on my face and end up eating crow for breakfast then that's a spectacularly benign outcome) this change is not going to go over well once it hits devel@. It is trust damaging, not trust building. If the security minded folks aren't so in love with this change that they're willing to get defend it tooth and nail, then I suggest they side with the user against the change, even if it's maybe contrary to better judgement. Because siding with the user will engender trust, it will de-escalate the controversy, should it materialize. And this earned trust can be used for recruitment on future needed work, it can be used for when you really really really need the user to change their behavior. Which is probably not now, nor in this fashion. And you don't have to criticize the Anaconda team to do that, you can leave that to jerks like me who eat crow for breakfast. All you have to do is say something like, hey we think this change is not worth the security enhancement compared to the usability impact and we are working on better defaults and hardening that don't require the user to change their behavior, while making it easier to opt in to better behaviors that have big impact, and we really need help and involvement from the community to realize all of that, please join us at our next meeting (or something like that). -- Chris Murphy -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
