SUMMARY It seems the kwallet Secret Service API is sending the wrong amount of bytes (or wrongly padded bytes) randomly. I am not 100% sure if this is a bug in kwallet or in libsecret. My guess it is a bug in kwallet however. See the reproducer below. STEPS TO REPRODUCE In bash run: ``` # Store a random secret, I use 'asdf' as secret value when prompted: secret-tool store --label="some random secret" attr1 val1 # Every 0.1 second try to retrieve the secret: while true; do G_MESSAGES_DEBUG=libsecret secret-tool lookup attr1 val1 ; sleep 0.1 ; done ``` OBSERVED RESULT After a while, maybe 3 seconds, maybe 4 minutes, you will see: ``` ... asdf libsecret-INFO: 17:22:03.571: received an invalid or unencryptable secret asdf ... ``` EXPECTED RESULT The message ``` libsecret-INFO: 17:22:03.571: received an invalid or unencryptable secret ``` should not appear. SOFTWARE/OS VERSIONS Operating System: Arch Linux ARM KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.21.0 Qt Version: 6.10.1 Kernel Version: 6.18.2-1-1-ARCH (64-bit) Graphics Platform: Wayland Processors: 8 × Apple Firestorm (M1 Pro), 2 × Apple Icestorm (M1 Pro) Memory: 31,0 GiB of usable RAM Graphics Processor 1: Apple M1 Pro Graphics Processor 2: llvmpipe Product Name: Apple MacBook Pro (14-inch, M1 Pro, 2021) ``` $ pacman -Qii libsecret ... Version : 0.21.7-1 ... ``` ADDITIONAL INFORMATION I am running KDE Plasma with KWallet with the old backend (https://planet.kde.org/marco-martin-2025-04-14-towards-a-transition-from-kwallet-to-secret-service/, which should be the default for most up-to-date KDE installs). Therefore I have two services running, ksecretd and kwalletd6: ``` $ ps aux | grep -E 'ksecretd|kwalletd' mkurz 805 0.0 0.0 701760 18000 ? SLl Jän03 0:19 /usr/bin/ksecretd --pam-login 12 13 mkurz 2077 0.0 0.0 832912 15216 ? SLsl Jän03 0:00 /usr/bin/kwalletd6 ``` My kde config has apiEnabled=true so kdewallet provides the Secret Service API (therefore two services running): ``` $ cat .config/kwalletrc # not showing all configs, not everyhing is relevant [Wallet] Default Wallet=kdewallet Enabled=true First Use=false Use One Wallet=true [org.freedesktop.secrets] apiEnabled=true ``` POSSIBLE CAUSE There are two places in libsecret where the error message occurs: https://gitlab.gnome.org/GNOME/libsecret/-/blob/068dc057420271b181555b69a4dbbf1f1d12f563/libsecret/secret-session.c#L457-463 https://gitlab.gnome.org/GNOME/libsecret/-/blob/068dc057420271b181555b69a4dbbf1f1d12f563/libsecret/secret-session.c#L534-540 However, both are "the same", both are within a `service_decode_aes_secret` method. Which of the two equal method gets compiled in just depends which crypto library is used (`#ifdef WITH_GCRYPT` vs `#ifdef WITH_GNUTLS`) So the real problem must be within the function pkcs7_unpad_bytes_in_place here, which "Validate the padding" which obviously fails: https://gitlab.gnome.org/GNOME/libsecret/-/blob/068dc057420271b181555b69a4dbbf1f1d12f563/libsecret/secret-session.c#L368-396 So either kwallet is sending "wrong" bytes which libsecret is unable to unpad - or kwallet is doing everything correct and libsecret is expecting a wrong format? You may know how to fix that, I am not so much into crypto nor did I code C in the last 22 years, so it would be great if you could figure out what and who is wrong here. Thanks! UNRELATED If you see following error: ``` libsecret-INFO: 17:34:10.260: Remote error from secret service: org.freedesktop.DBus.Error.InvalidArgs: Client public key size is invalid secret-tool: Client public key size is invalid ``` That can be ignored, this is a different bug in libsecret I just discovered as well and which is tracked (and hopefully fixed ;) here: https://gitlab.gnome.org/GNOME/libsecret/-/merge_requests/168
There was a similar issue in 2017 regarding "received an invalid or unencryptable secret": https://bugzilla.gnome.org/show_bug.cgi?id=778357 which got fixed with https://gitlab.gnome.org/GNOME/libsecret/-/commit/998065599c66055dcffa1ef1ddebb947ccd68248 (the code moved meanwhile and today can be found here: https://gitlab.gnome.org/GNOME/libsecret/-/blob/0.21.7/egg/egg-dh-libgcrypt.c#L186-190) It's not the same I know, today the issue is about kwallet with libsecret not playing nicely, back then it was gnome-keyring/libsecret: > Essentially the difference boils down to libsecret not performing any padding > on shared secret obtained from DH, while gnome-keyring does prepend null bytes. > Not sure which behavior is correct one, so this could apply to gnome-keyring instead.