Again? The password

[Michael Hennebry]

On Tue, 28 Jul 2015, Kevin Fenzi wrote:

> On Tue, 28 Jul 2015 17:39:55 -0500 (CDT)
> Michael Hennebry <hennebry at web.cs.ndsu.nodak.edu> wrote:
>
>>> The above is stuff thats all being worked on, yelling at anyone is
>>> unlikely to change the speed at which it gets done.
>>
>> What does "worked on" mean?
>
> I have been talking with pam, libpwquality, anaconda,
> gnome-initial-setup and passwd maintainers to come up with a technical
> way to implement a default policy. As well as a way to override it for
> local users or products that wish a different policy.

If "local users" means people typing in passwords, that is good.

> I have been spending a bunch of time exchanging emails, looking at
> libpwquality code and working out something everyone can implement.
>
>> It seem to me that that is precisely the issue.
>> It could mean fixing the problem.
>> It could mean setting it in stone.
>>
>> My expectation, and I think that of others,
>> is that for anaconda, it will be set in stone.
>
> What does 'set in stone mean'? The current behavior?
> No. The proposed policy (which I just submitted to fesco for approval)
> wouldn't be the same as the current anaconda behavior.

That would be good, but from what I can see,
the proposal does not specify a particular behavior.
It specifies parameters from which a policy can be generated.

>> Is there currently any reason to suppose that from now on
>> anaconda will not enforce its notion of strong passwords?
>
> Yes, because there will be a distro wide policy that anaconda (and
> other local password changing things) will follow.

No one was worried that there might not be a distro-wide policy.
The worry was that the policy would be truly annoying.

Happily, that seems not to be the case.
>From the proposed policy:

> We should have a base passphrase/password policy for applications to use.
> This allows them all to be consistent and also provide our users with
> needed security. Additionally, we should make it possible for our users
> to adjust this base policy as they need depending on their use cases.

> We should provide a way for users or products to adjust this policy,
> and also a way to allow overriding it (if the policy allows).

If "users ... overriding it" means that the person
typing in the password can just say yes, that is good.
If anaconda's policy does not allow, that would be bad.

>From what I can tell, anaconda might be shipped with a policy that requires
666-character passwords and does not allow the user to just say yes.

>> In case the current work includes the setting in
>> stone of anaconda's demand for "strong" passwords,
>> what can or should those who prefer
>> encouragement to enforcement do about it?
>
> Well, I would personally say you should wait until there was a proposed
> policy to look at. Now there is:
>
> https://fedorahosted.org/fesco/ticket/1455#comment:30
>
> Feel free to comment there or in the fesco meeting tomorrow.
>
> If there's a great deal of problem with it we could also push it back
> to a discussion on the devel list.
>
> The frustrating thing for me here is that I have been working on this
> (as my other piles of tasks permit) for a while now and then people come
> along and start yelling that it's not changed yet, and tell me that
> they refuse to wait until there's a proposal, they want to complain to
> anaconda folks now (who are also waiting until there's a fesco policy).

The *decision* to fix the annoyance that started
this discussion does not require waiting for fesco.
The anaconda folks can, if they so desire, make anaconda
warn about bad passwords without necessarily rejecting them.
It's possible that the anaconda folks promised to do just that.
If so, I missed it.
A pointer to said promise would be good news.

I've seen at least one case of vehemence
over clarity by a professional writer.
In the heat of the utterance, neither said writer nor most of his
readers noticed that he had not quite stated what they thought he had.

A sufficiently annoyed anaconda person might respond
with vehemence that they are working on it.
Not very informative if the reader suspects that they
do not share the same judgement of the status quo.
"working on it" might mean setting the status quo in stone*.



> I appreciate that this is a very hot button issue for some folks, and I
> also appreciate that you want a solution 2 weeks ago, but I'm doing the
> best I can here to move us all to a nice standard distro policy and we
> aren't even at alpha yet.

Again, the issue was never "how fast are we getting a policy?".
The issue was always "what policy are we getting?".

How many people usually participate in alpha?


* to set in stone -- to make something so permanent that to change
                      it takes effort akin to hammer and chisel work.

-- 
Michael   hennebry at web.cs.ndsu.NoDak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then."   --   John Woods