> Heyho David, Hi Markus
> 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. This patch does not change this. With this patch applied, for someone to tamper with the shift key and *not* make a change on the screen, their only option is to press and never release it. This is still quite suitable for the paranoid. Perhaps my commit message wasn't the clearest. At the end of the day, this patch was only meant to stop slock from flashing the failure colour if the correct password started with a shift+<something> key combination. It does not erase slock's tamper behaviour. > - 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. I agree, a third option isn't a good idea at all.
signature.asc
Description: PGP signature
