[plasmashell] [Bug 469951] Fingerprint auth times out after a certain number of seconds; after this, it can only be re-activated by entering your password incorrectly

https://bugs.kde.org/show_bug.cgi?id=469951

[email protected] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #10 from [email protected] ---
This is no solution for the bug, but a workaround for everybody who is annoyed
of not functioning fingerprint.
For me entering a wrong password did not reset the fingerprint. Claude helped
me add a button to the lock-screen that resets the entire greeter. This also
restarts fprintd and I can log in with fingerprint again, even if the previous
try timed out.

I did not look into security measures and if this button could be exploited to
run something else. Please be careful about this!!

Here is a more complete report, but is written by AI and not double checked
(Engineer here, no programmer):

################## CAUTION AI ##########################

Workaround: a lock screen button that restarts the greeter

Plasma 6.6.4, Wayland. This is a local workaround, not a fix — the 30 s window
is unchanged, it just makes running out of it cost one click instead of the
password.

Written by Claude Opus 5

A new greeter process is the only thing that reliably re-arms the fingerprint
stack here. ksld lives in kwin_wayland, not in the greeter, so killing the
greeter leaves the session locked and untouched while ksld respawns it.
Recovery measured at ~3.3 s from press to fingerprint unlock, with the new
greeter up 107 ms after the kill.

Three additions to
/usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockScreenUi.qml
(line numbers as shipped in 6.6.4):

1. After the import block (~line 20):

import org.kde.plasma.plasma5support as Plasma5Support

2. Inside the root Item, after id: lockScreenUi (~line 23):

    Plasma5Support.DataSource {
        id: fingerprintRetry
        engine: "executable"
        connectedSources: []
        onNewData: (sourceName, data) => disconnectSource(sourceName)
        function retry() {
            connectSource("/usr/bin/pkill -x kscreenlocker_g");
        }
    }

3. As the first entry of actionItems: (~line 297), beside Sleep / Hibernate /
Switch User:

                    ActionButton {
                        text: i18ndc("plasma_shell_org.kde.plasma.desktop",
"@action:button", "Retry &Fingerprint")
                        icon.name: "fingerprint"
                        onClicked: fingerprintRetry.retry()
                    },

Two things about that command that cost time to get right:

- kscreenlocker_g is not a typo. The kernel caps a process's comm at 15
characters, so pkill -x kscreenlocker_greet matches nothing and the button
silently does nothing. pgrep warns about this; pkill does not.
- pkill -f, as suggested in bug 506658, over-matches — -f tests the full
command line, which includes that of the shell running pkill itself.
- The absolute path is deliberate: the button runs unauthenticated from the
lock screen and shouldn't user-writable directory.

Notes for anyone trying this: LockScreenUi.qml is a package file, not a
conffile, so any plasma-desktoently. You can develop against it safely — copy
the shell package elsewhere, point XDG_DATA_DIRS at it,and use
kscreenlocker_greet --testing to load the QML in a window without locking
anything. And broken regardless: the greeter logs Failed to load lockscreen
QML, falling back to built-in locker and thebuilt-in locker still takes the
password.

-- 
You are receiving this mail because:
You are watching all bug changes.