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
Seems the commit hook doesn't like bug keywords on the title. This was fixed in: https://invent.kde.org/plasma/polkit-kde-agent-1/-/commit/c87f82883ff8d59c883e26b769c0135d4bfd9a8d