can't get rid of gnome-keyring (solved)

[Spanik]

I just installed my desktop again and one of the first things I installed as usual was the Vivaldi browser (being a user of Opera before). But very strange was when the first time I used it I got a window asking to set a password for "gnome-keyring". I find this very strange because a few weeks ago I installed a small mini-itx board and set on it also lxde and Vivaldi and there this window about gnome-keyring does not appear.

After some searching I found this old thread on the forum https://forums.gentoo.org/viewtopic-t-1 ... art-0.html I followed the advise that Alamahant gives in it, also added the use flags in my make.conf and did a "emerge --update --deep --changed-use @world".
Added also /etc/portage/package.use/vivaldi

Code: Select all

www-client/vivaldi -gnome-keyring

To make sure I added /etc/portage/package.use/pinentry

Code: Select all

app-crypt/pinentry -gnome-keyring

But no change. If I start Vivaldi I still get the window and what is worse

Code: Select all

# equery depends gnome-keyring
 * These packages depend on gnome-keyring:
app-crypt/pinentry-1.3.2-r1 (gtk ? gnome-base/gnome-keyring)
sys-auth/pambase-20251104 (gnome-keyring ? gnome-base/gnome-keyring[pam])
virtual/secret-service-0-r1 (gnome-base/gnome-keyring)

Even with the general "-gnome-keyring" and the /etc/portage/package.use/pinentry file it looks as if pinentry still uses gnome-keyring.

How can I get rid of this gnome-keyring?

[rab0171610]

Did you notice in your output:

Code: Select all

 These packages depend on gnome-keyring:
app-crypt/pinentry-1.3.2-r1 (gtk ? gnome-base/gnome-keyring) 

If pinentry is built with gtk then it now requires gnome-keyring.
In the 1.3.2-r1 ebuild:

Code: Select all

gtk? (
		app-crypt/gcr:4[gtk]
		gnome-base/gnome-keyring
	)

The other available stable version (1.3.1-r1) does not require this. If you were to package mask anything higher than 1.3.1-r1 then it can still be built with +gtk. Otherwise, if you stick with 1.3.2-r1, it would have to be built without gtk.

[sam_]

Note why it "now" requires it, per git log:

commit cff0a38faf832c83cf9e4f84b48a7f1cb99c6544
Author: Sam James <sam@gentoo.org>
AuthorDate: Sat Sep 6 22:16:56 2025 +0100
Commit: Sam James <sam@gentoo.org>
CommitDate: Sat Sep 6 22:17:08 2025 +0100

app-crypt/pinentry: depend on gnome-keyring with USE=gtk

With USE=gtk and only app-crypt/gcr:4 installed, I get:
```
$ G_MESSAGES_DEBUG=all G_DEBUG=all pinentry-gnome3
(process:503360): Gcr-DEBUG: 09:38:27.242: opening prompt
(process:503360): Gcr-DEBUG: 09:38:27.242: connecting to bus
(process:503360): Gcr-DEBUG: 09:38:27.245: connected to bus
(process:503360): Gcr-DEBUG: 09:38:27.245: calling BeginPrompting method on prompter
(process:503360): Gcr-DEBUG: 09:38:27.251: failed to register prompt org.gnome.keyring.SystemPrompter: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.keyri
ng.SystemPrompter was not provided by any .service files
(process:503360): Gcr-DEBUG: 09:38:27.251: closing prompt
```

If I install app-crypt/gcr:0, it starts to work, but that's because
app-crypt/gcr:0 depends on gnome-base/gnome-keyring.

We could switch the dep in pinentry to gcr:0 so we don't pull in 2 gcr
slots, but then we'd have to modify configure to avoid automagic on gcr:4,
and my hope is that the issue here will be fixed upstream at some point
(though it's not clear to me whose fault it is, see e.g.
https://gitlab.gnome.org/GNOME/gnome-ke ... issues/139 too).

TL;DR: depend on gnome-base/gnome-keyring to make pinentry-gnome3 work
again.

Closes: https://bugs.gentoo.org/960307
Signed-off-by: Sam James <sam@gentoo.org>

i.e. USE=gtk actually does need it to function.

[Hu]

But no change. If I start Vivaldi I still get the window and what is worse

Code: Select all

# equery depends gnome-keyring
 * These packages depend on gnome-keyring:
app-crypt/pinentry-1.3.2-r1 (gtk ? gnome-base/gnome-keyring)
sys-auth/pambase-20251104 (gnome-keyring ? gnome-base/gnome-keyring[pam])
virtual/secret-service-0-r1 (gnome-base/gnome-keyring)

Even with the general "-gnome-keyring" and the /etc/portage/package.use/pinentry file it looks as if pinentry still uses gnome-keyring.

How can I get rid of this gnome-keyring?

As we routinely tell people, don't use equery for this. Run emerge --pretend --verbose --depclean gnome-base/gnome-keyring and refer to the resulting output to understand why your system has gnome-keyring installed. In this specific case, sam_ explained why USE=-gnome-keyring is not enough. If you really want not to have gnome-keyring, consider setting USE=-gtk on pinentry and relying solely on the non-GUI version of pinentry. This obviously may be less usable, so the decision depends on your environment whether you can tolerate that trade.

Alternatively, fix Vivaldi so that you can keep gnome-keyring and still eliminate the prompt from Vivaldi.

[Spanik]

Ok, so I first changed /etc/portage/package/pinentry to

Code: Select all

app-crypt/pinentry -gtk -gnome-keyring

Next I ran "emerge --update --changed-use --deep @world". It only rebuild pinentry.

if I do then "emerge --pretend --verbose --depclean gnome-base/gnome-keyring " it tells me that gnome-keyring is to be removed. I then let it remove gnome-keyring. Followed by a reboot.

I start Vivaldi and again the first it asks is a password for the keyring.

"emerge --update --changed-use --deep @world"

Code: Select all

# emerge --verbose --depclean gnome-base/gnome-keyring
--- Couldn't find 'gnome-base/gnome-keyring' to depclean.
>>> No packages selected for removal by depclean

Bit of a loss here. I'm going to mask now anything higher than 1.3.1-r1 for pinentry.

PS: if I do a google search for "gentoo checking dependencies", the first 2 entries that link to gentoo.org are for equery... So sorry about using equery to check about who wanted gnome-keyring.

[Spanik]

added /etc/portage/package.mask/pinentry

Code: Select all

>=app-crypt/pinentry-1.3.2

followed by "emerge --update --deep @world" and "emerge --update --deep --depclean" and that seemed to work.

Thanks!

[rab0171610]

You may want to copy that current ebuild directory with the lower version of pinentry to a local repository.

https://wiki.gentoo.org/wiki/Handbook:A ... repository

[Spanik]

You may want to copy that current ebuild directory with the lower version of pinentry to a local repository.

I have been using Gentoo for a long time but that is very new to me. I guess you want to say to make a local copy of that ebuild that does not require the keyring so that if it ever gets "lost" by subsequent evolution that I still can go back to it. I'm going to read that but I'm a bit afraid that it is over my head.

[Hu]

What is the goal here? The thread mainly talks about wanting to remove gnome-keyring. We achieved that, by configuring pinentry not to use any GUI based prompts. By pursuing that path, we can keep gnome-keyring out even with new versions of pinentry. Then OP masked newer pinentry, which does not make sense to me. Per sam_'s post, the newer pinentry is correct to insist on gnome-keyring when using a GUI, so installing an older pinentry seems wrong. Moreover, the thread's real complaint seems to be about Vivaldi asking for a password, and the successful removal of gnome-keyring had no effect on Vivaldi. So is the goal (a) remove gnome-keyring, and ignore Vivaldi's behavior or (b) make Vivaldi stop asking for a password, at any cost? If (b), then it seems like removing gnome-keyring was not useful, since it required removing pinentry GUI support, and did nothing to stop Vivaldi.

[Spanik]

What is the goal here? The thread mainly talks about wanting to remove gnome-keyring. We achieved that, by configuring pinentry not to use any GUI based prompts. By pursuing that path, we can keep gnome-keyring out even with new versions of pinentry. Then OP masked newer pinentry, which does not make sense to me. Per sam_'s post, the newer pinentry is correct to insist on gnome-keyring when using a GUI, so installing an older pinentry seems wrong. Moreover, the thread's real complaint seems to be about Vivaldi asking for a password, and the successful removal of gnome-keyring had no effect on Vivaldi. So is the goal (a) remove gnome-keyring, and ignore Vivaldi's behavior or (b) make Vivaldi stop asking for a password, at any cost? If (b), then it seems like removing gnome-keyring was not useful, since it required removing pinentry GUI support, and did nothing to stop Vivaldi.

The goal was to stop Vivaldi asking for a password for gnome-keyring each time it starts (at any cost *). First try was to set use "-gtk" and "-gnome-keyring" for pinentry. This did not make any difference as Vivaldi kept asking for the password for the keyring. And gnome-keyring continued to be in @world after --depclean. So going to an earlier version of pinentry stopped Vivaldi asking the password for the keyring and enabled --depclean to remove gnome-keyring.

That is how I understand the steps I took.

[rab0171610]

You are correct Hu. I did not understand from the conversation that the earlier version of pinentry should also require gnome-keyring but does not.

Considering everything that HU pointed out, I wanted to add some additional information.

https://chromium.googlesource.com/chrom ... storage.md

Code: Select all

On Linux, Chromium can store passwords in five ways:

    GNOME Libsecret
    KWallet 4
    KWallet 5
    KWallet 6
    plain text

Chromium chooses which store to use automatically, based on your desktop environment.

Passwords stored in KWallet are encrypted on disk, and access to them is controlled by dedicated daemon software. Passwords stored in plain text are not encrypted. Because of this, when KWallet is in use, any unencrypted passwords that have been stored previously are automatically moved into the encrypted store.

Support for using KWallet was added in version 6, but using these (when available) was not made the default mode until version 12.
Details

Although Chromium chooses which store to use automatically, the store to use can also be specified with a command line argument:

    --password-store=gnome-libsecret (to use GNOME Libsecret)
    --password-store=kwallet (to use KWallet 4)
    --password-store=kwallet5 (to use KWallet 5)
    --password-store=kwallet6 (to use KWallet 6)
    --password-store=basic (to use the plain text store)

Note that Chromium will fall back to basic if a requested or autodetected store is not available.

So if you want to avoid kwallet or gnome-keyring the only other alternative is basic (unecrypted and not necessarily safe) mode. You can force this by editing the vivaldi.desktop file or when starting vivaldi from the command line:

Code: Select all

/usr/bin/vivaldi-stable --password-store=basic

[rab0171610]

So going to an earlier version of pinentry stopped Vivaldi asking the password for the keyring and enabled --depclean to remove gnome-keyring.

That is how I understand the steps I took.

Just be aware that this may be using plain text to save passwords from websites as I pointed out in my previous post. You might not be able to rely on being able to avoid installing gnome-keyring indefintely. I am not encouraging it, but gnome-keyring is the only application I keep an entry for in package.provided. In that case the application is just not found and chromium browsers would default to basic plain text password storage. The safest option would be to use gnome-keyring. If you choose not to, the other option would be to start vivaldi with the --password-store=basic command line argument as long as you are willing to accept the security risk.

[Hu]

And gnome-keyring continued to be in @world after --depclean.

What do you mean by this? I thought you successfully removed gnome-keyring, and it should never have been in your world set at all. If it was on the system, it should have been there only as a dependency, which we fixed above.

What is the output of emerge --pretend --verbose app-crypt/pinentry ; emerge --pretend --verbose --depclean gnome-base/gnome-keyring?

[CooSee]

as an additional tip - here's a list of chrome based commands https://peter.sh/experiments/chromium-c ... word-store

[Spanik]

And gnome-keyring continued to be in @world after --depclean.

What do you mean by this? I thought you successfully removed gnome-keyring, and it should never have been in your world set at all. If it was on the system, it should have been there only as a dependency, which we fixed above.

I never added gnome-keyring to my @world, it was likely pulled in as a dependency.

After adding "-gtk -gnome-keyring" to /etc/portage/package.use/pinentry I ran "emerge --update --changed-use --deep @ world". Followed by "emerge --pretend --verbose --depclean gnome-base/gnome-keyring " which told ne "nothing to do". Starting Vivaldi still asked for the password to the keyring. I then ran "emerge --search app-crypt/gnome-keyring" and it was still there listed as being installed (1.3.2-r1).

Next I added "/etc/portage/package.mask/pinentry" and set that to ">=app-crypt/pinentry-1.3.2". The ran "emerge --update --changed-use --deep @ world" followed by "emerge --pretend --verbose --depclean". This removed 18 packages including gnome-keyring. Since then Vivaldi starts without asking for the keyring password.

What is the output of emerge --pretend --verbose app-crypt/pinentry ; emerge --pretend --verbose --depclean gnome-base/gnome-keyring?

Code: Select all

# emerge --pretend --verbose app-crypt/pinentry ; emerge --pretend --verbose --depclean gnome-base/gnome-keyring

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 2.58 s (backtrack: 0/20).

[ebuild   R    ] app-crypt/pinentry-1.3.1-r1::gentoo  USE="X ncurses qt6 wayland -caps -efl -emacs -gtk -keyring (-verify-sig)" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

 * IMPORTANT: 8 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

--- Couldn't find 'gnome-base/gnome-keyring' to depclean.
>>> No packages selected for removal by depclean

Just be aware that this may be using plain text to save passwords from websites as I pointed out in my previous post. You might not be able to rely on being able to avoid installing gnome-keyring indefintely. I am not encouraging it, but gnome-keyring is the only application I keep an entry for in package.provided. In that case the application is just not found and chromium browsers would default to basic plain text password storage. The safest option would be to use gnome-keyring. If you choose not to, the other option would be to start vivaldi with the --password-store=basic command line argument as long as you are willing to accept the security risk.

Duly noted. Thing is that it is unclear to me is what exactly is saved by this keyring. And how it is used by which applications. But that is a completely different discussion.

[rab0171610]

Just be aware that this may be using plain text to save passwords from websites as I pointed out in my previous post. You might not be able to rely on being able to avoid installing gnome-keyring indefintely. I am not encouraging it, but gnome-keyring is the only application I keep an entry for in package.provided. In that case the application is just not found and chromium browsers would default to basic plain text password storage. The safest option would be to use gnome-keyring. If you choose not to, the other option would be to start vivaldi with the --password-store=basic command line argument as long as you are willing to accept the security risk.

Duly noted. Thing is that it is unclear to me is what exactly is saved by this keyring. And how it is used by which applications. But that is a completely different discussion.

What is saved by the key ring is your passwords for websites that you save so that you do not have to enter them every single time. Most people probably use this feature. These passwords are encrypted when using gnome-keyring or kwallet.

I do not agree that it is a completely different discussion. Moving forward, pinentry will require gnome-keyring. You have temporarily bypassed that by using package.mask. Your solution is not a solution but a temporary workaround.

In the future, you will need to embrace gnome-keyring or kwallet, or you will need to launch vivaldi with the --password-store=basic command line argument. The only other way to avoid this and let vivaldi fall back to basic unencrypted mode by default would be to ensure that gnome-keyring is not present on your system. The only way to do that would be to add gnome-keyring to package provided (most will likely not recommend you to do that), rename the gnome-keyring binary so that it is not found by vivaldi or make it not executable (which you would have to do every time gnome-keyring is updated), or maintain your own ebuilds (and possibly patches) in a local repository that would prevent gnome-keyring being installed as a dependency.

Enjoy the temporary workaround, but eventually after a future update, you will be right back in the situation you found yourself in now.

[Hu]

And gnome-keyring continued to be in @world after --depclean.

What do you mean by this? I thought you successfully removed gnome-keyring, and it should never have been in your world set at all. If it was on the system, it should have been there only as a dependency, which we fixed above.

I never added gnome-keyring to my @world, it was likely pulled in as a dependency.

That is as it should be. You wrote earlier that it was in @world, which is why I asked this.

After adding "-gtk -gnome-keyring" to /etc/portage/package.use/pinentry I ran "emerge --update --changed-use --deep @ world". Followed by "emerge --pretend --verbose --depclean gnome-base/gnome-keyring " which told ne "nothing to do". Starting Vivaldi still asked for the password to the keyring. I then ran "emerge --search app-crypt/gnome-keyring" and it was still there listed as being installed (1.3.2-r1).

That is strange. As far as I can tell, gnome-keyring has never been in app-crypt.

Code: Select all

$ git log -1 github/master -- app-crypt/gnome-keyring/
$ git log -1 github/master -- gnome-base/gnome-keyring/
commit 2b7260cf9049e67c9071a010bf9d4bbf7e903b49
$ git log -1 github/master
commit 6a2bedf59e9daeaf67bf74018fc9f0f2762cadca (github/master)

Next I added "/etc/portage/package.mask/pinentry" and set that to ">=app-crypt/pinentry-1.3.2".

Per sam_'s explanation above, I think this was wrong. Don't mask newer versions unless you are prepared to maintain the old one indefinitely.

The ran "emerge --update --changed-use --deep @ world" followed by "emerge --pretend --verbose --depclean". This removed 18 packages including gnome-keyring.

Which gnome-keyring did it remove: gnome-base/gnome-keyring (which you said above was not installed, since depclean found nothing to do) or app-crypt/gnome-keyring (which, as far as I can tell, has never existed in Gentoo's Portage tree)?

[Spanik]

What is saved by the key ring is your passwords for websites that you save so that you do not have to enter them every single time. Most people probably use this feature. These passwords are encrypted when using gnome-keyring or kwallet.

I do not agree that it is a completely different discussion. Moving forward, pinentry will require gnome-keyring. You have temporarily bypassed that by using package.mask. Your solution is not a solution but a temporary workaround.

In the future, you will need to embrace gnome-keyring or kwallet, or you will need to launch vivaldi with the --password-store=basic command line argument. The only other way to avoid this and let vivaldi fall back to basic unencrypted mode by default would be to ensure that gnome-keyring is not present on your system. The only way to do that would be to add gnome-keyring to package provided (most will likely not recommend you to do that), rename the gnome-keyring binary so that it is not found by vivaldi or make it not executable (which you would have to do every time gnome-keyring is updated), or maintain your own ebuilds (and possibly patches) in a local repository that would prevent gnome-keyring being installed as a dependency.

Enjoy the temporary workaround, but eventually after a future update, you will be right back in the situation you found yourself in now.

Since you want to take it further, I'm at loss as which passwords are saved. The cases I see are:
- passwords of sites like this forum. I have to give ID and password and then I choose to stay logged in. But AFAIK this is done by session cookies from the site you visit. In any case when I wipe the cookies I have to log in again.

- passwords related to sites like my bank. There isn't really a password to store. There is only and ID and the rest is 2FA.

- the ones I'm not sure on are those from shops and auction sites. You have an account there and need to log in with ID and password. But then I never have the browser ask to store the password.

I must add that is is my habitude to set the browser to:
- not store passwords
- not store payment methodes
- not allow sites to check for saved payment methods
- not allow the browser to save and fill addresses
- not allow search in the address bar
- not allow search in the history
- not let google services do autofill
- lots of other things are set to "block" like autoplay, geolocation, automatic downloads, bluetooth, midi...

Maybe I'm a bit paranoid.

After adding "-gtk -gnome-keyring" to /etc/portage/package.use/pinentry I ran "emerge --update --changed-use --deep @ world". Followed by "emerge --pretend --verbose --depclean gnome-base/gnome-keyring " which told ne "nothing to do". Starting Vivaldi still asked for the password to the keyring. I then ran "emerge --search app-crypt/gnome-keyring" and it was still there listed as being installed (1.3.2-r1).

That is strange. As far as I can tell, gnome-keyring has never been in app-crypt.

That is my fault, pinentry is in app-crypt, not gnome-keyring. Typing too quickly and not checking.

[Juippisi]

The goal was to stop Vivaldi asking for a password for gnome-keyring each time it starts (at any cost *).

Does launching vivaldi with

Code: Select all

vivaldi-stable %U --password-store=basic

still work?