Anaconda 22.17+ enforces "good" passwords

[Chris Murphy]

On Thu, Feb 26, 2015 at 11:37 AM, Stephen John Smoogen <smooge at gmail.com> wrote:
>
>
> On 26 February 2015 at 11:25, Chris Murphy <lists at colorremedies.com> 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 at . 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