Talk:GNOME/Keyring
How to use with applications
"and make them available to applications." ... how do you use it?(firefox?) What applications are supported? the gnome page unclear as usual...Jasper1984 (talk) 11:39, 25 August 2012 (UTC) Edit: modification made to add it. Jasper1984 (talk) 11:50, 25 August 2012 (UTC)
- The modification was Special:diff/219686, yet it is gone along with Special:diff/650325. The current article has GNOME/Keyring#Integration with applications to list related crosslinks.
- --Indigo (talk) 22:11, 30 January 2023 (UTC)
Using the keyring outside GNOME with a a display manager (SDDM) =
From the article it seems that the keyring (no matter how it is called) is automatically unlocked by SDDM if the password matches the login password. Also it seems that it is not necessary to modify /etc/pam.d/sddm. Is this correct? This seems not to happen with sddm 0.17.0. Is this a bug? —This unsigned comment is by Simgunz (talk) 08:23, 2 July 2018 (UTC). Please sign your posts with ~~~~!
xinitrc method does not work
The method described for .xinitrc does not unlock the keyring. A comment on This reddit post suggests the PAM method must be used in conjunction for it to work, but this wiki proposes the PAM method as standalone. quequotion (talk) 06:13, 10 October 2019 (UTC)
Launching gnome-keyring-daemon outside desktop environments (KDE, GNOME, XFCE, ...)
Emptty login manager doesn't execute scripts in /etc/X11/xinit/xinitrc.d/ automatically. Also, user sway configuration doesn't automatically include /etc/sway/config.d/50-systemd-user.conf. It's better to know what's going on under the hood so that people remember dbus-update-activation-environment and why they need it instead of 50-systemd-user.conf.
Amano 2022-08-03
- I'd like to drop the removed section for the manual start here, the info may be useful for handling the template. --Indigo (talk) 20:48, 24 January 2023 (UTC)
gnome-keyring-daemon dropped its ssh-agent with 1.46
The page mentions "From GNOME 41 (released September 2021) until at least this writing (April 2023), the SSH functionality of gnome-keyring-daemon has been duplicated into /usr/lib/gcr-ssh-agent, which is part of gcr. The eventual plan is to remove the implementation in gnome-keyring-daemon, but that effort seems to have stalled."
It appears this un-stalled in October 2023, with this change disabling the ssh agent in gnome-keyring-daemon in the default build configuration: https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/60
That change has been included in gnome-keyring-daemon 1.46 and beyond. (This broke the integration for me until I found a reddit post that pointed me at the change: https://www.reddit.com/r/archlinux/comments/1aq97m8/gnomekeyring_14601_in_extratesting_disables/)
I guess some of the non-gcr-based approaches should now be marked obsolete in the wiki or removed entirely. Jpab (talk) 22:52, 17 February 2024 (UTC)
Security model
Seems like Red Hat and Gnome both disputed this. Suggesting to use sandboxed applications instead:
- Nowadays sandboxed applications (flatpak, snap, etc.) are more common than when this issue was reported five years ago. ... E.g. flatpak apps' access to the session bus is restricted via xdg-dbus-proxy. The sandboxed application is therefore unable to use the libsecret D-Bus API; instead, it has to use the credentials portal, which grants access only to a partitioned subset of the secrets.[1]
Sounds like, they have no plan to fix this security issue in gnome-keyring for native software programs (apps installed using distros package managers).
Arash (talk) 14:22, 19 February 2024 (UTC)
- It was reworded with Special:diff/801066. Closing. Cheers. --Indigo (talk) 22:30, 26 February 2024 (UTC)
I have noticed the changes. Thank you all for the quick reaction.
However, not so unrelated to this, is the OO7 project[2]. A Secret Service provider[3]
Look at the reference links above for details; but in short, I think, it's going to replace the desktop-specific APIs used by Gnome Keyring. And provide API to migrate from host secrets to sandboxed ones.
Some considerations are:
- It's not done yet. Perhaps, it's too early to document it. It will probably land with Gnome v46 or v47.
- How this will affect the current behaviour of Gnome Keyring regarding distribution packages.
- Arash (talk) 10:19, 27 February 2024 (UTC)
- Interesting. If you have a reference clarifying it is meant to replace the API in official upstream, please add it sometime. I reopen the item, to avoid the info being purged. --Indigo (talk) 20:53, 28 February 2024 (UTC)
No ssh-agent list command
The wiki suggests running "ssh-agent -l" after setting up SSH, but there's no such command. Not sure from the context if this should be using "ssh-add" instead. MariaSolOs (talk) 21:56, 15 September 2024 (UTC)
SSH_AUTH_SOCK environment variable with gcr-ssh-agent
The wiki currently states:
> Manual configuration of SSH_AUTH_SOCK environment variable shall not be necessary, if gcr-ssh-agent.socket unit is active. The value of SSH_AUTH_SOCK environment variable shall be set to $XDG_RUNTIME_DIR/gcr/ssh after user logs out and logs in. This is known to work with Gnome Console application for user using fish as default shell.
However, using ZSH and a simple console based login, SSH_AUTH_SOCK is not set in the shell. I would like to propose editing the wording of this to indicate that automatic setting of this env var is more likely not to happen and give an example of how to set it. The example:
_ssh_auth_sock=$(systemctl --user show-environment | grep ^SSH_AUTH_SOCK)
if [ -n "$_ssh_auth_sock" ]; then
export SSH_AUTH_SOCK=$(echo "$_ssh_auth_sock" | cut -d= -f2-)
fi
If this would be accepted I'll make the edit. I'm new to contributing to the Wiki and thought making a discussion first would be the better approach. MatthiasK (talk) 10:18, 19 November 2024 (UTC)
invalid default gcr ssh socket path
Section 5.1 Setup gcr states $XDG_RUNTIME_DIR/gcr/ssh.
But the source code is always using .ssh instead of ssh as a file name.
The fix requires changing gcr-ssh-agent.socket and gcr-ssh-agent.service systemd units.