Re: [Tails-dev] #5594: tails-greeter: better administration …

Nachricht löschen

Nachricht beantworten
Autor: anonym
Datum:  
To: The Tails public development discussion list
Neue Treads: Re: [Tails-dev] #5594: tails-greeter: better administration password UI
Betreff: Re: [Tails-dev] #5594: tails-greeter: better administration password UI
12/05/14 17:41, intrigeri wrote:
> anonym wrote (12 May 2014 15:02:45 GMT) :
>> That makes a lot of sense in t-p-s since we *force* the persistent
>> container to be encrypted with a password. But for the Greeter's
>> *optional* admin password I'm note sure it makes sense.
>
> I don't think it makes any sense. Sorry, I'm probably the one who
> wrote a misleading (not to say: stupid) description on this ticket.
>
>> IMHO this change is a severe loss of functionality, and either:
>
>> 1. we have to admit that requesting this was a mistake, and keep the
>>    current behaviour.

>
> As far as "can't be empty" is concerned, right, we should keep the1
> current behaviour.


Ok. Since Andres' patch doesn't add anything else, we'll have to
completely drop it. Again, I'm really sorry for having wasted your time,
Andres!

>> 3. I've completely misunderstand what the ticket asks for. I believe it
>>    was you, intrigeri, who filed the ticket (before it was imported to
>>    redmine). Could you please elaborate on the purpose and arguments
>>    for this change, if this is what you actually intended?

>
> The rest of the suggested changes make sense to me. The t-p-s UI is
> way nicer, with a nice little warning dynamically updated as long as
> entered password confirmation does not match. And I stole it from
> GNOME Disks, iirc, which makes the UX more consistent.


Note that we have some form of "dynamic behaviour" for the error (from
commit c96200f [1]) but that it's not exactly the same as in t-p-s; the
mis-match error is only shown after trying to login when the fields
differ, and the error is immediately removed when one of the fields
change. IMHO this is a better behaviour than always showing it, at least
in the Greeter's context where we do not have a default error to show
(like "passphrase can't be empty" in t-p-s).

Given that the semantics of the fields are pretty different in the
Greeter compared to in t-p-s, please provide a detailed description of
how you think the Greeter should be changed in case you still think it's
desirable.

Cheers!

[1] Its commit message refers to "consitent [sic] behaviour when
compared to the warning shown for MAC spoofing while inside a VM", a
warning which eventually was removed since it was based on a wrong
interpretation of a bug. That's why it was implemented in a seemingly
unrelated branch (feature/mac-spoof).