https://linux.debian.bugs.dist.narkive.com/1gNoFD0j/bug-994961-glib2-0-gnome-keyring-unable-to-unlock-login-keyring-on-some-systems-since-glib-2-70-0-1
According to this post, glib2 has hardened security in version 2.70, but gnome-keyring hasn't adapted to it yet.
My gnome-keyring package version is the latest in Artix stable branch: 1:40.0-1
Symptoms:
- Any program that requires gnome-keyring stored password (for example, nextcloud-client) doesn't work.
- When you press keyboard shortcut Ctrl-Alt-T it takes about 25 seconds to open gnome-terminal (DBUS timeout)
If you downgrade to glib2 version 2.68 it works again.
It is an upstream problem but, is there any solution from here? Can glib2 version 2.70 package be returned to testing?
Well, at least users reading this post can downgrade glib2 to solve the problem.
Could be something else which is causing this problem. I have glib2 version 2.70 and gnome-keyrinng 1:40.0 installed in Arch. gnome-keyring works fine. But thanks for letting us know the workaround.
~ » pacman -Qs glib2
local/glib2 2.70.0-1
Low level core library
~ » pacman -Qs gnome-keyring
local/gnome-keyring 1:40.0-1 (gnome)
Stores passwords and encryption keys
I don't have Artix install at hand. Can somebody check if the packages are from the same repos?
~ » pacman -Ss glib2
core/glib2 2.70.0-1 [installed]
Low level core library
~ » pacman -Ss gnome-keyring
extra/gnome-keyring 1:40.0-1 (gnome) [installed]
Stores passwords and encryption keys
$ pacman -Ss glib2
system/glib2 2.70.0-1 [instal·lat: 2.68.4-1]
Low level core library
$ pacman -Ss gnome-keyring
world/gnome-keyring 1:40.0-1 (gnome) [instal·lat]
Stores passwords and encryption keys
Looks like they're from Artix repos. Not sure how they're re-packaged from Arch packages, but they're different from size. Need Artix package maintainers to look into it.
Arch:
-----/var/cache/pacman/pkg » ls -asl glib2-2.70.0-1-x86_64.pkg.tar.zst*
2824 -rw-r--r-- 1 root root 2890132 Sep 17 17:29 glib2-2.70.0-1-x86_64.pkg.tar.zst
4 -rw-r--r-- 1 root root 141 Sep 17 17:29 glib2-2.70.0-1-x86_64.pkg.tar.zst.sig
/var/cache/pacman/pkg » ls -asl gnome-keyring-1:40.0-1-x86_64.pkg.tar.zst*
828 -rw-r--r-- 1 root root 846674 Sep 21 23:57 gnome-keyring-1:40.0-1-x86_64.pkg.tar.zst
4 -rw-r--r-- 1 root root 141 Sep 14 12:28 gnome-keyring-1:40.0-1-x86_64.pkg.tar.zst.sig
Artix:
------artix-live:[artix]:/var/cache/pacman/pkg$ ls -asl glib2*
2828 -rw-r--r-- 1 root root 2892753 Sep 18 04:53 glib2-2.70.0-1-x86_64.pkg.tar.zst
4 -rw-r--r-- 1 root root 566 Sep 18 04:54 glib2-2.70.0-1-x86_64.pkg.tar.zst.sig
artix-live:[artix]:/var/cache/pacman/pkg$ ls -las gnome-keyring*
828 -rw-r--r-- 1 root root 845447 Mar 26 2021 gnome-keyring-1:40.0-1-x86_64.pkg.tar.zst
4 -rw-r--r-- 1 root root 566 Mar 26 2021 gnome-keyring-1:40.0-1-x86_64.pkg.tar.zst.sig
These are the Artix packages sources:
glib2
------
https://gitea.artixlinux.org/packagesG/glib2/src/branch/master/x86_64/core
gnome-keyring
----------------
https://gitea.artixlinux.org/packagesG/gnome-keyring/src/branch/master/x86_64/extra
https://gitea.artixlinux.org/packagesL/libgnome-keyring/src/branch/master/repos/extra-x86_64
I'm using Cinnamon desktop.
Hi all.
I have problem wirh gnome-keyring-damen and secrets for two days.
At the end problem was the capability of /usr/bin/gnome-keyring-daemon
The gnome-keyring.install of pacman PKGBUILD give cap_ipc_lock to gnome-keyring-daemon with setcap command.
I remove this capability from daemon and all works fine
Hey Everyone,
On upgrade to glib2-2.70.0-1 my gnome session crashes out on login (right after lightdm hands off). I vaguely remember setting my login keyring to unlock for the user ... so most likely not a coincidence.
In the short term is `setcap -r /usr/bin/gnome-keyring-daemon` a working solution or should I wait on glib2-2.68.4 until something comes from the repos?
I just found this affects my Nextcloud-client too. Have just downgraded to glib2-2.68 as well.
On this PC, running Manjaro with a similar set up, it is running 2.70 fine!
I am on 2.68.4. Would like to wait for Artix dev to update.
Looking into this, it seems like the workaround for now, according to these gnome-keyring (https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/77) and glib (https://gitlab.gnome.org/GNOME/glib/-/issues/2305) issues is to remove the cap_ipc_lock capability from gnome-keyring. I'm a bit surprised Arch hasn't done that already, but I'll just update the gnome-keyring install script to not do that capability (and remove it for upgrades) for now.
Any chance to keep cap_ipc_lock in gnome-keyring-daemon? Personally, I don't like the daemon to swap its memory which keeps sensitive info out to swap storage.
Somehow, Arch manages to keep the cap and make it work flawlessly.
[liveuser@archlinuxgui ~]$ pacman -Qs glib2
local/glib2 2.70.0-1
Low level core library
[liveuser@archlinuxgui ~]$ pacman -Qs gnome-keyring
local/gnome-keyring 1:40.0-1 (gnome)
Stores passwords and encryption keys
[liveuser@archlinuxgui ~]$ getcap /usr/bin/gnome-keyring-daemon
/usr/bin/gnome-keyring-daemon cap_ipc_lock=ep
[liveuser@archlinuxgui ~]$ ps -ef | grep gnome-keyring-daemon
liveuser 1564 539 0 16:27 ? 00:00:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
liveuser 1646 1638 0 16:28 pts/1 00:00:00 grep gnome-keyring-daemon
[liveuser@archlinuxgui ~]$ cd /proc/1564
[liveuser@archlinuxgui 1564]$ cat limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 30463 30463 processes
Max open files 1024 524288 files
Max locked memory 1048576 1048576 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 30463 30463 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
That doesn't make any sense really. There's no difference between the Arch or Artix package. Same thing for glib2. I don't use it myself, but this shouldn't work on Arch either as far as I understand it.
See if this link helps.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c2a3e929650d327c5f57ec2f646b1cb749d60843 (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c2a3e929650d327c5f57ec2f646b1cb749d60843)
That disables libcap in the build and removes the capability. I'm not sure if that's better/worse than just removing it. Maybe it's better.
The Debian bug mentions a $XDG_RUNTIME_DIR/bus which apparently is created by dbus.socket and of course is missing in non-systemd distros.
For now, I have removed the .install file that does the setcap. It should land in gnome-keyring-1:40.0-1.1.
Mh that's not enough. "--without-libcap-ng" needs to be add to ./configure, otherwise libcap-ng gets picked up by default if installed and the capability is set in the Makefile (https://gitlab.gnome.org/GNOME/gnome-keyring/-/blob/40.0/Makefile.am#L104). After that libcap-ng can also be removed from the dependencies.
Oh that's sneaky. It should be gone now in 1:40.0-1.2.
(https://i.imgur.com/oVeubu0.png)
Thank you very much! 👍