Bug 514194 - kwallet bug: received an invalid or unencryptable secret
Summary: kwallet bug: received an invalid or unencryptable secret
Status: REPORTED
Alias: None
Product: frameworks-kwallet
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: 6.21.0
Platform: Other Linux
: NOR major
Target Milestone: ---
Assignee: Valentin Rusu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-01-05 17:07 UTC by m.kurz
Modified: 2026-01-08 08:20 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description m.kurz 2026-01-05 17:07:31 UTC
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
Comment 1 m.kurz 2026-01-08 08:20:18 UTC
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.