Is Signal installed from Flatpak?

(In reply to Nicolas Fella from comment #1)
> Is Signal installed from Flatpak?

apt from signal.org repository, according to instruction in 11-2021
remainder from installation is /etc/apt/sources.list.d/signal-xenial.list
recent instruction creates signal-desktop.sources with same contents, instead

I have a similar issue. I recently upgraded to KDE 6.5 and since then Vivaldi cannot read the Wallet. Interestingly, in my case, Signal can.

Vivaldi prints:
> KeystoreChecker: Profile Default: Encryted keystore changed or is now unavailable. This may result in lost cookies and other problems.

Then, it refuses to load the profile at all and it suggests to start from scratch.

Frank, when you open "kwalletmanager" from Alt+F2, is your kdewallet open? If you open it, do you see any actual content (passwords, maps, etc.) within the entries?

In my case, when I opened it yesterday, the entries existed but their content was all empty. Then I rebooted and now the content is back...

In my case I jump between X11 and Wayland because of various bugs and the X11 default on openSUSE. I don't know how this application handles logging out from X11 and logging back to Wayland, but hopefully it shouldn't be a problem.

This is the debug log from the browser (nothing too interesting, it tells that it found the right provider):

>VERBOSE1:chromium/components/os_crypt/sync/key_storage_util_linux.cc:49] Password storage detected desktop environment: KDE6
>VERBOSE1:chromium/components/os_crypt/sync/key_storage_linux.cc:139] Selected backend for OSCrypt: KWALLET6
>VERBOSE1:chromium/components/os_crypt/sync/key_storage_linux.cc:209] OSCrypt using KWallet as backend.
>VERBOSE1:chromium/components/os_crypt/sync/os_crypt_linux.cc:218] Decryption failed
>WARNING:extraparts/vivaldi_keystore_checker.cc:79] KeystoreChecker: Decryption of the canary failed. Keystore may have changed!
>ERROR:extraparts/vivaldi_keystore_checker.cc:163] KeystoreChecker: Profile Default: Encryted keystore changed or is now unavailable. This may result in lost cookies and other problems.
>WARNING:extraparts/vivaldi_keystore_checker.cc:28] KeystoreChecker: AskShouldAllowInsecureAccess: UI Is not available yet. Returning NO to insecure access
>ERROR:extraparts/vivaldi_keystore_checker.cc:168] KeystoreChecker: Keystore unlock failed and user requested profile switch!

Is there a way to inspect the communication between KWallet and the browser?

Frank, this is the solution that worked for me: https://forum.vivaldi.net/topic/109314/solved-can-not-pass-profile-launcher-after-update . 

Basically, within KWalletManager:

1. Use File > Export Encrypted to back up the current key storage.
2. Close, then Delete the entire key storage (same menu) named kdewallet.
3. Import the previously backed up key storage using File > Import Encrypted.
4. Another bug here, too: quit KWalletManager, and killall ksecretd and kwalletd6 (otherwise you wouldn't see the newly imported wallet and it wanted to recreate a new one with an "_1" appended to it..). Then restart all of them.
5. Start your misbehaving applications

It fixed Vivaldi for me.

I analysed the difference of the D-bus communication of both the bad and the good wallets. The only difference was in this call:

```diff
 ‣ Type=method_call  Endian=l  Flags=2  Version=1 Cookie=X  Timestamp="X"
   Sender=:D  Destination=:F  Path=/org/freedesktop/secrets  Interface=org.freedesktop.Secret.Service  Member=GetSecrets
   UniqueName=:D
   MESSAGE "aoo" {
           ARRAY "o" {
-                  OBJECT_PATH "/org/freedesktop/secrets/collection/kdewallet/1";
                   OBJECT_PATH "/org/freedesktop/secrets/collection/kdewallet/0";
           };
-          OBJECT_PATH "/org/freedesktop/secrets/session/33";
+          OBJECT_PATH "/org/freedesktop/secrets/session/1";
   };
```

It seems in the bad case (marked with minus), there was another kdewallet collection (/1) and Vivaldi could not handle this case. Deleting and re-importing the very same wallet fix it somehow.

There was another diff but I don't know if it's expected because of different timestamp or wallet:

```diff
 ‣ Type=signal  Endian=l  Flags=1  Version=1 Cookie=X  Timestamp="X"
   Sender=:F  Path=/ksecretd  Interface=org.kde.KWallet  Member=walletAsyncOpened
   UniqueName=:F
   MESSAGE "ii" {
-          INT32 22;
-          INT32 1433144397;
+          INT32 3;
+          INT32 1920261253;
   };
```

(In reply to Szőts Ákos from comment #3)
> I have a similar issue. I recently upgraded to KDE 6.5 and since then
> Vivaldi cannot read the Wallet. Interestingly, in my case, Signal can.

There were major changes from Plasma 6.3.6 to Plasma 6.5, most notably a big refactor of kwallet in KDE Frameworks 6.14. It's very likely your bug is not the same bug as OP.

(In reply to Frank Busse from comment #0)
> Linux/KDE Plasma: Debian GNU/Linux 13
> KDE Plasma Version: 6.3.6
> KDE Frameworks Version: 6.13.0
> Qt Version: 6.8.2

Frank, I suggest you file a bug with Debian. KDE Frameworks 6.13 is somewhat outdated now, and importantly, predates some significant refactoring in kwallet, so this is not very actionable on KDE's side. But Debian might be able to apply some local patches.

I created separate reports for Bug 511982 and Bug 511983.

(In reply to Szőts Ákos from comment #3)
> Frank, when you open "kwalletmanager" from Alt+F2, is your kdewallet open?
Yes

I have accidentally found out that, after dist-upgrade to trixie, both kWallet and /usr/bin/gnome-keyring-daemon are active. (I previously was and still am on KDE/Plasma.) Is there any use in having both? Can I find out why gnome-keyring-daemon was added?

(In reply to Frank Busse from comment #10)
> I have accidentally found out that, after dist-upgrade to trixie, both
> kWallet and /usr/bin/gnome-keyring-daemon are active. (I previously was and
> still am on KDE/Plasma.) Is there any use in having both? Can I find out why
> gnome-keyring-daemon was added?

gnome-keyring-daemon tends to be installed by default on some systems. It may have already been there before the update, or may have been pulled in as a "recommended" dependency. It used to be the main provider of Secret Service API, but nowadays KWallet can also provide that API (as of 5.97 or so).

You can check if you have any secrets stored in gnome keyring (e.g. using Seahorse), and if not, try uninstalling the daemon. It can sometimes conflict with other Secret Service providers such as KWallet, so it's best to remove it if you don't need it.

Btw, re your original issue, try also checking if there are any permission problems, such as SElinux blocking access to KWallet. And check your block list in KWalletManager. (Though Debian should be using AppArmor by default, IIRC.)

(In reply to michaelk83 from comment #11)
> You can check if you have any secrets stored in gnome keyring (e.g. using
> Seahorse), and if not, try uninstalling the daemon.

thx for the hint. After removing gnome-keyring (and restart), "busctl --user list | grep secrets" now shows kwallet to be active, and krdc uses kwallet. Only the original issue with signal remains unsolved.

> SElinux blocking access to KWallet.

SElinux not installed, only libs req'ed by systemd.

> And check your block list in KWalletManager.

?? where is a "block list" in kWalletManager?

(In reply to Frank Busse from comment #12)
> ?? where is a "block list" in kWalletManager?

Settings > Configure Wallet > Access Control
It not likely to have changed just from an upgrade, but worth a check just in case.

(In reply to michaelk83 from comment #13)
> > ?? where is a "block list" in kWalletManager?

Sorry - I was looking for a separate list of blocked apps, in kWalletManager... :-/

> Settings > Configure Wallet > Access Control

No, nothing blocked.