Re: [dev] [bug] slock gets red before submitting pass

From: David Phillips <dbphillipsnz_AT_gmail.com>
Date: Thu, 28 Jan 2016 11:26:48 +1300

On Wed, Jan 27, 2016 at 05:16:55PM +0100, FRIGN wrote:
> On Wed, 27 Jan 2016 13:58:56 -0200
> Brad Luther <bradkluther_AT_gmail.com> wrote:
>
> Hey Brad,
>
> > I think I found a bug on slock.
>
> No this is not a bug.
>
> > If you're typing your password and gets a char wrong, you go and
> > delete the char, then continue to type the pass and 'enter' to unlock
> > the screen. All good, screen is blue all the time.
> > Unless... you get the first char wrong. If you mistype the first char
> > of your password and 'backspace' to delete it, the screen goes red
> > even though you didn't 'enter' the wrong password.
>
> The wanted behaviour is that if somebody touches your computer and types
> anything on the computer, the screen has to be either red or blue.
> red indicating a typing attempt of wrong pw and blue meaning that
> currently something is being entered.
> When you remove a character from a password string, which is not the
> last, slock thinks you are still in editing mode (which is true) so
> it shows blue.
> Now, if you remove the last char, for slock you are like the evil
> coworker typing something in but then thinking: shit, there he is
> coming! quick, remove the entry.
> It's all a security measure so you can see when you go back to your
> computer that someone fucked with it.
>
> Cheers
>
> FRIGN
>
> --
> FRIGN <dev_AT_frign.de>
>
Hi all,

FRIGN is right, there is an underlying motive for this behaviour. Perhaps
it could/should be documented somewhere, I don't know.

You have reminded me, however, that one regret I have since implementing
this behaviour is that pressing a modifier key (especially the shift key)
will turn the screen red, since a keypress has occurred and the password
buffer is empty.

But yes, the failure colour on the screen after emptying the password buffer
is desired behaviour for sure.

--
David

Received on Wed Jan 27 2016 - 23:26:48 CET

This archive was generated by hypermail 2.3.0 : Wed Jan 27 2016 - 23:36:10 CET