Bug 510038

Summary:	Chromium-based applications sometimes unable to find keys
Product:	[Frameworks and Libraries] frameworks-kwallet	Reporter:	Andrew Todd <at+kdebugs>
Component:	general	Assignee:	Valentin Rusu <valir>
Status:	REPORTED ---
Severity:	normal	CC:	kdedev, kdelibs-bugs-null, nate, notmart
Priority:	NOR
Version First Reported In:	6.18.0
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Andrew Todd 2025-09-29 06:13:20 UTC

SUMMARY

There's an ongoing discussion in the Signal Desktop bugtracker (https://github.com/signalapp/Signal-Desktop/issues/7439) where, since August 2, a number of people have suddenly been unable to unlock their Signal Desktop database when the decryption key was stored in kwallet; one user also reports that Slack, also an Electron application, had a similar problem.

As some others have done, I was able to fix the issue by using an older backup of my wallet files.

I do not know if the issue originates in kwallet or in Chromium or somewhere in between, but I am hoping that you might be able to provide some insight.

I should also note that for a brief period of time I was unable to log in to a Mastodon server using Tokodon; I do not know if this is related. That seems to have fixed itself.

STEPS TO REPRODUCE

I am unable to pin down what triggered this. Some people experienced this two months ago, but it only happened to me last week.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2

ADDITIONAL INFORMATION

The only relevant difference between the old KDE Wallet metadata file (`kdewallet_attributes.json`) and the new one was this:

    "Chromium Keys/Chromium Safe Storage__0_": {
        "$fdo_created": "...",
        "$fdo_mime_type": "text/plain",
        "$fdo_modified": "...",
        "attributes": {
            "server": "Chromium Keys",
            "type": "plaintext",
            "user": "Chromium Safe Storage",
            "xdg:schema": "org.qt.keychain"
        }
    },

Prior to this there was already a similar entry, which still exists in the file:

    "Chromium Keys/Chromium Safe Storage": {
        "$fdo_created": "...",
        "$fdo_modified": "...",
        "attributes": {
            "server": "Chromium Keys",
            "type": "plaintext",
            "user": "Chromium Safe Storage"
        }
    },

Comment 1 Marco Martin 2025-10-06 12:38:19 UTC

as i answered on the upstream bug, I wasn't able so far to reproduce with Signal.

I have some questions to hopefully get a better idea:

* is the app running from flatpak or installed system-wide?
* since it seems the Chromium Safe Storage entry got duplicated, are both of them visible in kwalletmanager?
* if they are, do they have the same password inside? (you might also try to look at them on a secretservice client, such as keepsecret or seahorse)
* copying the password from the old to the new one, does it make the app work again?
*if you backup the signal's data folder, and do a setup from scratch, does the app work from now on?

Comment 2 Andrew Todd 2025-10-09 08:02:25 UTC

(In reply to Marco Martin from comment #1)

Thanks for responding. I can't be sure that the issue is specific to kwallet but it does seem to trend in that direction.

> * is the app running from flatpak or installed system-wide?

Both Signal and Chromium are installed system-wide as regular Arch packages on my system, not Flatpaks.

> * since it seems the Chromium Safe Storage entry got duplicated, are both of
> them visible in kwalletmanager?

When investigating my working wallet with kwalletmanager, here's the Chromium-related entries that I see:

* Chromium Keys -> Passwords -> Chromium Safe Storage
* xdg-desktop-portal -> Binary Data -> org.chromium.Chromium
* xdg-desktop-portal -> Binary Data -> chromium

However, I can't figure out how to load my broken wallet files in kwalletmanager so I can view them. I see "Import a wallet" as an option under the File menu, but I don't want to do that.

My memory is that there were no additional entries shown.

> * if they are, do they have the same password inside? (you might also try to
> look at them on a secretservice client, such as keepsecret or seahorse)

I have checked Arch's package manager and searched online, but I can't find any program called `keepsecret`. You'll have to point me to it.

Seahorse shows four Chromium-related entries: the three I mentioned above, plus another one in the root called "Chromium Safe Storage" that contains the same password as "Chromium Keys -> Passwords -> Chromium Safe Storage" above. As with kwalletmanager, I don't know how to view the wallet files that caused the problem in this application.

> * copying the password from the old to the new one, does it make the app
> work again?

I fixed things by restoring an old copy of my wallet files. When I did so, Signal started working again, however, at the same time, Chromium forgot all of its cookies and whatever other data was encrypted with the key.

Based on this, here's my best-guess hypothesis: Signal bundles its own copy of Chromium, which is usually older than the version of Chromium I'm installing directly. For some reason, they rely on the same encryption key.

Either Signal or Chromium was upgraded -- I'm guessing Chromium -- and did something to regenerate the key, which broke the other application. I note that someone on GitHub also had trouble with the Slack desktop app; I don't use the Slack desktop app.

I wasn't able to find anything relevant in the Chromium bugtracker that might have triggered this. I've looked at the published changelog for Chrome, but that doesn't usually include this level of detail. The full change logs from this page:

https://www.chromium.org/developers/change-logs/

are so massive and keywords like "key" or "password" have so many results that I wasn't able to go through all of them.

If my guess is correct, the heart of the problem is that two applications are using the same key. Is there anything we can do to help change this?

> *if you backup the signal's data folder, and do a setup from scratch, does
> the app work from now on?

I have not tried this.