5.42.0 now asks for keyring when starting up

[jrw]

• [X] I have searched open and closed issues for duplicates

• [X] I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

---

Bug Description

I just upgraded to Signal desktop 5.42.0 (on Linux Mint 20). When I stop and restart Signal, it is now asking "Choose password for new keyring"

Steps to Reproduce

1. Close Signal application via window decoration X close application
2. Restart Signal application via desktop shortcut
3. Choose "Cancel" on keyring dialog and again on following keyring dialog

Actual Result:

When I stop and restart Signal, it is now asking "Choose password for new keyring" "An application wants to create a new keyring called "Default keyring". Choose the password you want to use for it." This dialog locks up the entire user interface. I am able to cancel it (it comes back again immediately, but I can cancel it a second time), after which Signal starts as normal and I am able to use it normally. This repeats the next time I stop/restart Signal.

Expected Result:

When I stop and restart Signal, the application interface starts as normal and I am able to interact with it without answering any dialogs.

Screenshots

Platform Info

Signal Version: 5.42.0

Operating System: Linux Mint 20

Linked Device Version:

Link to Debug Log

https://debuglogs.org/desktop/5.42.0/59524b819542f797d3cb686e4cfe91c0b23e13bf37ddeebcc2d3b1019d1aee91.gz

[scottnonnenberg-signal]

Hm. This is quite odd - what if you try to start Signal with this command-line argument? --password-store=basic

[scottnonnenberg-signal]

(found this forum thread: https://forums.linuxmint.com/viewtopic.php?t=312289)

[jrw]

Thanks for your reply Scott!

Using --password-store=basic makes the problem disappear. It must be related somehow to the issue you found with Chromium, because I see that I also get that popup for Chromium (which I don't use very often).

I haven't investigated (much) the Chromium issue via your link, but I can add the "password-store" thing to my launcher for Signal and for Chromium. However, why should this have appeared with the latest release of Signal? Do you think it's a Linux Mint thing, or did something in that Signal release trigger it somehow? And what is causing Signal and Chromium to be related in this weird way?

[scottnonnenberg-signal]

We updated to Electron 18 in 5.42, and that came with an updated version of Chromium.

[jrw]

OK. Thanks! So, is adding the --password-store option the right fix? Does the Signal installer need to add that option to the launcher command line?

[scottnonnenberg-signal]

It certainly might; it's interesting, though, because we haven't seen this report from many folks. I guess they have a default keyring already set up?

[jrw]

Maybe others have a default keyring because of using chromium? I use chromium only when I have to (which is very seldom)

[jrw]

I've found one more place this would need to be changed if there is an update: the Startup Applications command line for Signal under the Preferences grouping. (The original one was the Signal launcher command line.)

[tillschaefer]

Can conform the issue on KDE, where I have to grant access to my wallet for each application individually.

[Geblaat]

I have the same issue on Debian 11. I don't use Chromium so never setup a keyring.

[beantaco]

I also experience this issue on Debian 11. I have never seen the keyring password window until the recent software update.

[reglos]

This will happen only if the keyring is not unlocked automatically, which is usually done when you enter username/password at login. If you enable booting to the desktop without user authentication, you get the unlock dialog when the first application tries to use the keyring. This explains, why only few people are affected.

[beantaco]

This will happen only if the keyring is not unlocked automatically, which is usually done when you enter username/password at login. If you enable booting to the desktop without user authentication, you get the unlock dialog when the first application tries to use the keyring. This explains, why only few people are affected.

I believe the first two statement are true. However, the final statement is not exactly true...

• We don't know how many people are or are not affected.
• It doesn't explain why people are affected.

I have used Signal Desktop for a long time, and version 5.42 is when I have first seen the keyring unlock prompt. It seems to me that Signal Desktop (or its upstream) clearly changed upon updating. Furthermore, I authenticate with my username/password at login, so I don't know why I am being prompted for a password when I launch Signal Desktop.

Upon inspection of my GNOME keyring using Seahorse, there are 2 entries containing "Chrome" or "Chromium" that I believe are related to Signal Desktop:

Chrome Safe Storage Control

• password: (a very generic phrase)
• use: saved password or login
• type: password
• details: (a dummy entry related to http://crbug.com/660005 *)

Chromium Safe Storage

• password: (base64 encoded 128-bit key)
• use: saved password or login
• type: password
• details: "application: Signal"

I never use GNOME keyring, and my GNOME keyring is empty except for these two logins.

Has Signal Desktop (or its Chrome/Chromium based upstream) been changed to start using GNOME keyring? If so, why?

* Redirects to https://bugs.chromium.org/p/chromium/issues/detail?id=660005

[ScriptForAll]

I use Manjaro with XFCE and also experience this issue since the last update.

I don't know if this is relevant but I get the same kind of prompt when I open Brave Browser.

[beantaco]

What is the effect of GNOME keyring on Signal Desktop? What is the difference between entering a password to unlock the keyring and not entering it? Did the Signal Desktop entry in GNOME keyring exist prior to version 5.42?

[iago-lito]

Hi there, I also experience the issue on a fresh arch install, and it was present last week on previous (up-to-date-yet-cluttered) arch install.

[scottnonnenberg-signal]

We'll get a fix for this out in 5.45. Thanks for the reports, everyone!

[beantaco]

I haven't seen the keyring dialog appear for a while, maybe since I installed 5.45.x but I'm not sure exactly when.

[1231231231231231231231231]

Since the last two comments confirm a fix for the old problem (and #6944 furthermore opines this is now desired behavior) this old ticket can be closed right? When searching for the problem that appeared in a recent update, this ticket appeared on top so, it being open, at first I didn't realise it is in fact an old and resolved thread

[jrw]

I have been using /opt/Signal/signal-desktop --password-store=gnome-libsecret --no-sandbox %U rather than using --password-store=basic for the past several months.

[apteryks]

We'll get a fix for this out in 5.45. Thanks for the reports, everyone!

For the record, I'm still seeing this behavior. I do not use seahorse (the GNOME password keyring), which I expressly disable via this file in ~/.config/autostart/gnome-keyring-secrets.desktop:

[Desktop Entry]
Hidden=false
...

[mfc]

We'll get a fix for this out in 5.45. Thanks for the reports, everyone!

i still get this issue, in debian 12 with signal desktop 7.67.0.

[jamiebuilds-signal]

@mfc Can you share a debuglog? https://support.signal.org/hc/en-us/articles/360007318591-Debug-Logs-and-Crash-Reports

[mfc]

@mfc Can you share a debuglog? https://support.signal.org/hc/en-us/articles/360007318591-Debug-Logs-and-Crash-Reports

sure, just submitted one