So I just did a full upgrade and now I get prompted to unlock the keyring for Brave browser everytime its launched.
In the past when I was distrohopping another distro that had xfce I would get that same prompt with Ungoogled-chromium and also Vivaldi which are both chromium based.
Its weird considering I never even use a browser keyring password manager I dont get why it prompts this.
Anyway the fix always used to be purge gnome-keyring however this doesn’t seem to be the best choice.
When you type sudo apt purge gnome-keyring it will show the other dependencies to remove are kicksecure-desktop-environment-essential-xfce and other Kicksecure specific ones so obviously I chose NOT to go forward.
The only fix in the meantime that is better is to add the chrome flag --password-store=basic which will ingore using GNOME keyring or kwallet (KDE).
So you would edit your launcher Exec=/usr/bin/browser --password-store=basic for the browser application or you could edit your /usr/share/application/browser.desktop file for desktop file but this might get updated with new updates so launcher seems like the safer bet.
Back to the point why is gnome-keyring dependency needed and could something be added to Kicksecure like above to automatically fix this pesky issue or to the wiki regarding chromium unlock keyring prompt with gnome-keyring.
Solution add the chrome flag --password-store=basic
Even if we find a technical solution to do this reliably by default [1], I am not sure we should change chromium default keystore settings. Comments welcome.
[1] We would probably have to solve the stackable wrappers issue.
Its a bad idea security wise to use a password manager in any browser aka saving passwords in the browser.
Is my understanding wrong that is what this is relates to kinda tho? As I stated I never stored any so idk why it needed to unlock anything when there was no passwords to begin with?
Maybe it is but also a popular feature. For example, browser internal password storage function can be safely used for low importance logins (those unlikely or unimportant if these get hacked).
So I did sudo dummy-dependency --yes --purge gnome-keyring and then rebooted into user persistent. I was never had the keyring popup window by both chromium and brave-browser. Additionally I can report that I never had that popup for the ProtonVPN GUI app.
Things I noted was that both browsers and ProtonVPN GUI took longer to initially load. I’m not sure if that was for each time or the initial first load. I’ll see if there is anything in terminal that shows errors or anything related to gnome-keyring, Secret Service DBus API, or password storage. After I check that I’ll report back on what I find.
If this is no security issue I might change the SolutionSolution~~ add the chrome flag --password-store=basic~~ here and suggest maybe shipping a dummy dependency for gnome-keyring.
Also I created another user (separate from user and sysmaint) in sysmaint panel as a test and it no popup was for the newly created user either.
Like I mentioned before there is not a way for distros currently to my knowledge to include a some type of drop in file for changing this. If you modified the exe= path where the binary is stored, well any new updates would change the file upon update of the browser. If you create a either a desktop shortcut or a panel icon for the browser and edit the exec path there they will survive updates to the browser.
Shipping a dummy dependency seems like the best fix given the way things are. Not sure how much LXQt relies on GNOME so this should be the safest bet as to avoid removing any other dependencies the desktop env needs from GNOME.
Keep in mind there are applications that absolutely require a “secret service” (like what gnome-keyring provides) of some sort. For instance, the Fractal Matrix client will simply refuse to operate if it can’t find a secret service. KeePassXC has secret service support, but it doesn’t work out of the box, and a feature request to make it usable as the default secret service for a distro was denied:
Removing gnome-keyring isn’t really an option as a result, it will break things even if some apps can get along without it. Replacing it with a different secret service provider would be possible, but we’d need to know what provider to use instead, and why it is superior to gnome-keyring.
What percentage of people even use gnome-keyring for applications? Better yet I wonder how many applications require it and refuse to work without it?
Yeah I saw that issue and was kinda disappointed since keepassxc seems to be the best and imo most secure password manager aground in 2026.
Does XMPP, IRC clients and other messengers rely on it “secret service”?
I have been prompted for it with Gajim (XMPP) but I was able to disable it and not sure how I fixed it.
It’s difficult to know, and even for those applications that do work without it, it’s unclear what features will be disabled or misbehave because of it not being there. A secret service is just an expected part of a working Linux desktop setup, applications use secret service APIs and we should not break them IMO.
I do 100% agree that storing passwords in gnome-keyring is probably less than ideal, and that using in-browser password managers is bad and whatnot, but the secret service can be used for storing arbitrary secret data in a more secure way than “dump it to an unencrypted file on the disk”, and we don’t know what data applications will store there. Users have the option of just not storing their passwords there if they don’t want to, there’s no need to remove it.
The main issue is chrome browsers and their handling of secret service. If users don’t click cancel on the popup, the browser simply wont work in my experience. Now you got me second guessing this fix as I have only been messing with browsers at the moment not messengers right now. Anyone following this thread please take note of this.
From what I know about why browser choice was included and why no browser is included by default. If there was ever a way to include some kind of fix without violating the licensing particular to Mozilla that would be great. I strongly advise people to not store passwords in the browser and if they do then install a separate browser with browser-choice for isolation (e.g auth cookies or passwords for accounts) for browsers that you wish to do that.
Would browsers follow /etc/skel/ and can it even support .desktop files? Like /etc/skel/.config is valid but is /etc/skel/.local/share/applications/?
One can also click to continue without entering a password, then confirm that they’re OK with proceeding with no password. That’s what I generally do. (The best experience would be if the secret service simply worked in the background without ever prompting the user for anything; maybe there’s a way to tell gnome-keyring to just operate without a password and stay quiet? That would be best since we rely on disk encryption to protect against human adversaries, and password protection of the secret service is probably better as a hardening measure taken by the end-user.)
/etc/skel is files that are included in newly created user accounts. We try to avoid using it, since existing user accounts won’t get any settings that are set there. System-wide configuration should be placed in something like /usr/share/applications. I’m not quite sure how desktop files are relevant here though.
Well if you modify lets say /usr/share/applications/brave-browser.desktop, or chromium and append the --password-store=basic at the end of the exec= all users will launch the browser without being prompted. However the new updates (apt-upgrades) overwrite these files. If there was a way to drop in this handling it would be a better user experience with chrome based browsers.
/usr/local/share/applications/ are not managed by APT?
Alternatively, if using GDM and LUKS, GDM can unlock your keyring if it matches your LUKS password. For this to work, you need to use the systemd init in your mkinitcpio.conf as well as the appropriate kernel parameters, and you should make sure that your system’s real-time clock is set to UTC rather than local time (see [2]). See [3] for more details.
GDM is too heavily tied to the GNOME desktop for us to want to use it probably. Unlike gnome-keyring which can act more-or-less standalone, GDM is highly integrated with the GNOME desktop.
That sounds like something we’d have to maintain going forward; Chromium has command-line options added and removed “at the whim of the developers”. Chasing that isn’t something we probably want to spend resources on. It would be better for all use cases if the keyring could be configured to “just work” without user interaction.