Bug 505239

Created attachment 182046 [details]
Screen recording demonstrating the bug

SUMMARY
On an account with password hash method set to yescrypt with YESCRYPT_COST_FACTOR set to 11, a couple seconds after a GUI password prompt window pops up, the prompt window "shakes" as if an incorrect password was entered and deletes any entered characters. It does *not* display an "Authentication failure" alert after this, and entering the password after this works normally.

STEPS TO REPRODUCE
1. Log in to a graphical KDE session with a user in the `wheel` group.
2. Edit `/etc/login.defs` to set `YESCRYPT_COST_FACTOR 11`.
3. Change the user password (so it's re-hashed with the new settings).
4. Run `pkexec` or `run0` in a terminal.
5. Immediately enter a few random characters when the password prompt opens.
6. Wait a few seconds.

OBSERVED RESULT
The password prompt window unexpectedly shakes and resets after a couple seconds. The attached screen recording shows this.

EXPECTED RESULT
The password authentication window shouldn't unexpectedly reset itself.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora Kinoite version 42.20250605.0 (tested in a freshly installed VM with no other changes after installation and updating)
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Polkit version: 126

ADDITIONAL INFORMATION
I tested this with various yescrypt cost factors, and this bug only seems to occur with YESCRYPT_COST_FACTOR >= 9. The delay between the password prompt opening and resetting is shorter the smaller the cost factor is, and with cost factor 9 it's usually just a fraction of a second. This seems like it must be a race condition of some sort.

Also, this may or may not be related, and is more subtle, but I think the password prompt is also slower to appear with a higher yescrypt cost factor. This seems strange to me, since the hashing method should only affect what needs to be done *after* the password is entered, right?

The system logs don't seem to show anything relevant: `journalctl -u polkit.service` shows nothing except polkit.service starting successfully when the system was booted.

I'm unsure whether this is a bug in policykit-kde-agent-1 or in Polkit itself, so I've also reported this to Polkit: https://github.com/polkit-org/polkit/issues/569