Little wishes for wf-locker

[AKArien]

A list of wishes that (i imagine should be) simple enough to have for the locker and would greatly improve it :

Functionality i believe would be good :

Generic config :

• for certain options, i’m not sure it’s a good idea to put a maximum. Sure, usually the contrained values are realistically within the range proposed, but if someone wants to go further is there a reason to not allow it ? for the following options :
  • prewake
  • all of the icon sizes
  • lockout_timer
• lockout_attempts : allow a value of 0 to signify no lockout.
• option to completely hide the fingerprint reader’s locker visual if there is no error
• detection of a (non-matching) fingeprint as « activity » for the purposes of hiding animations

Default configuaration changes i would do for aesthetic considierations

• move the fingerprint indicator’s default position to one of the middle slots, i would find it « cleaner » to have all of the « unlocking » in the middle

For the last two, while they are disabled if there is no pin/weather, i still think it would be cleaner to just disable them by default.

• i would personally think that the pin unlock should be off by default, since it requires setting one with wf-locker-pin, is for convenience at the cost of security, and password is already a solid default
• weather : since weather is an option of wf-shell that isn’t enabled unless requested at build, i would think it should be off by default

[trigg]

prewake

This one is simply because we need to know how long the parent process should last if the child crashes. At this point there is no config-reading ability so I put a cap here. It could be extended but not realistically removed. Unless we move config-reading up to pre-application stage.

icon sizes

as there's a serious issue with impossible to unlock locker if things are misconfigured I'm not sure 'no limit' is a good idea

lockout_timer

As this is the nearest we get to security, I'm loathe to allow lower than 10 second on timeout. There's no cap on attempts so the user could reliably set allowed login attempts into the millions and never see a lockout.

lockout_attempts

I don't believe this is a good candidate for allowing the user to disable entirely.

hide the fingerprint reader...

I might be misunderstanding. Hide while 'Waiting for fingerprint' ? I'd argue this is a really bad idea as there's always the chance that something malicious is repeatedly attempting sudo malicious_command in the background just waiting for you to touch the fingerprint reader. Clear positive feedback before fingerprinting is essential to fprintd

fingeprint as « activity »

Actually I thought it was... certainly agree on this one

fingerprint ... to one of the middle slots

Sure. Default isn't set in stone as it hasn't seen a release yet

pin unlock off by default

Sure, again. Not particularly fussed, but it made sense not to double-disable it while testing it

weather ... off by default

Anyone going to lengths to set up weather can manage the one extra step of enabling it, I agree.

[AKArien]

I see, that clears things up !

I do see why you are attached to the lockout, but i am saying this knowing that it’s not ideal for security.

I guess the better candidate for lockout-less would be to just allow a time of lockout as 0. I am thinking of how things like gnome and gtklock handle wrong passwords, they just stall for a few seconds and don’t fully lock out ; or perhaps is it the configuration of the distributions i used ? either way, i could see myself using a lockout of a few seconds on each wrong password, as a compromise between security and convencience.

[trigg]

From my own experience after 3 failed attempts both of those lock out for 10 minutes. You also cannot use a TTY or SSH to login with the same user in the timeframe.