Re: [dev] [PATCH] [slock] React to key release rather than key press events

From: Markus Teich <markus.teich_AT_stusta.mhn.de>
Date: Thu, 28 Jan 2016 08:30:15 +0100

David Phillips wrote:
> Previously, if failonclear was set to True and a modifier key (especially
> shift) was pressed and held in order to modify the next keypress, slock would
> detect that a keypress had been made, observe that the buffer was clear and
> set the screen to the failure colour.
>
> That behaviour is unwanted if the first key in a password is 'shift'. The new
> behaviour will still turn slock to the failure colour if the shift key is
> pressed, but only once it is released and the buffer is still clear.

Heyho David,

I don't think we should change the current behaviour. As already explained there
are two different ways of operation:

- The paranoid option / failonclear = true:
  Here you will leave your screen green and will notice ANY fiddling with the
  keyboard. Let's say someone assumes he has to press shift 20 times to crash
  the screenlocker. This will get noticed in the current code state as it will
  turn the screen red.

- The not so paranoid option / failonclear = false:
  Here the screen will only turn red after a failed unlock attempt. Therefore
  you would not notice a coworker playing some drum line on the shift key or
  even on any other key if he resets the buffer before you come back.

You propose to make the first option less paranoid, but I cannot see a reason
for that. I also don't think introducing another mode of operation is a good
idea. We have basically covered both ends of the paranoia range and a third
option would just compicate the code.

--Markus
Received on Thu Jan 28 2016 - 08:30:15 CET