regression: gnome-keyring components can't be disabled anymore
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| gnome-keyring (Ubuntu) |
Wishlist
|
Dimitri John Ledkov | ||
| Trusty |
Wishlist
|
Unassigned | ||
| Utopic |
Wishlist
|
Unassigned | ||
| Vivid |
Wishlist
|
Dimitri John Ledkov |
Bug Description
To disable gnome-keyring ssh agent,
- disable gnome keyring ssh in startup applications
To disable gnome-keyring gpg agent,
- disable gnome keyring gpg in startup applications
If above are disabled, stock ssh-agent & gpg-agent upstart jobs are used instead.
=====
SRU tests
By default environment should have SSH & GPG agent variables pointing at gnome-keyring provided ones.
Disabling gpg or ssh gnome keyring desktop files in "Startup Applications" upon next login stock gpg/ssh agent's will be used. (No gnome-keyring name in the SSH/GPG agent variable values)
Similarly, disabling upstart jobs for ssh or gpg agent also enables stock ssh/gpg agents. (e.g. echo manual > ~/.config/
=====
GNOME Keyring is by default a rather invasive service, which meddles with security sensitive processes invasively. This may or may not be wise depending on a users situation.
One particular case is GNOME Keyring's gpg-agent implementation, which is incomplete and therefore doesn't support GPG's OpenPGP smartcard support. gpg simply fails (with smartcards) when GNOME Keyring is impersonating gpg-agent...
So to be able to use OpenPGP smartcards on Ubuntu, one needs to disable GNOME Keyring from impersonating gpg-agent, which for quite some time now has been trivial to effectively do:
echo 'X-GNOME-
With GNOME Keyring's recent update (3.10.1-1ubuntu4.1) in Trusty, this seems to have been broken by the addition of:
/usr/share/
So it seems the /etc/xdg/
What is unclear to me is what the upstart session configuration is supposed to achieve? And if it is meant to supplant the xdg/autostart files, those should probably have been removed to prevent them from causing any confusion as to how gnome-keyring is started/managed.
Presuming the upstart session is meant to stay, I would suggest to remove the /etc/xdg/
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: gnome-keyring 3.10.1-1ubuntu4.1
ProcVersionSign
Uname: Linux 3.13.0-39-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Oct 29 18:14:57 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-04-07 (205 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Beta amd64 (20140326)
SourcePackage: gnome-keyring
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile.
description: | updated |
description: | updated |
Dimitri John Ledkov (xnox) wrote : | #2 |
Changed in gnome-keyring (Ubuntu): | |
status: | New → Won't Fix |
assignee: | nobody → Dimitri John Ledkov (xnox) |
importance: | Undecided → Wishlist |
Dimitri John Ledkov (xnox) wrote : | #3 |
We can't remove xdg files, as there are session types that are not managed by upstart.
Hence to disable or override the options passed to gnome-keyring should be done via job override for upstart managed sessions or the xdg autostart file for non-upstart managed sessions.
There is no bridge/compatiblity to inherit xdg disabled flags, to also disable upstart jobs.
Mike Berkley (mike-berkley) wrote : | #4 |
This same bug affects ssh keys, since gnome-keyring cannot handle ECDSA keys.
Dimitri John Ledkov (xnox) wrote : Re: [Bug 1387303] Re: regression: gnome-keyring components can't be disabled anymore | #5 |
On 30 October 2014 01:51, Mike Berkley <email address hidden> wrote:
> This same bug affects ssh keys, since gnome-keyring cannot handle ECDSA
> keys.
*sigh*
I presume the following things cannot be handled by gnome-keyring:
* gpg smartcards
* gpg smartcards, used for ssh authentication
* ECDSA ssh keys
* ECDSA gpg (2.1 beta)
However, the upstart jobs tries hard to _not_ override existing agents:
[ -z "$SSH_AUTH_SOCK" ] || [ -z "$GPG_AGENT_INFO" ] || { stop; exit 0; }
Thus if one has an ssh or gpg agent set before gnome-keyring job is
spawned, it's not suppose to take over.
However on my machine things are a bit strange:
GPG_AGENT_
GNOME_KEYRING_
SSH_AUTH_
GNOME_KEYRING_
So ssh-agent & secrets agents are GNOME_KEYRING, and gpg-agent is
provided by gnupg.
I think the logic in the job is a bit wrong, and it will always,
actually attempt to override the first agent.
I presume we want the pkcs11 gnome-keyring component? (That's for e.g.
normal ssl smartcards right?!)
As currently implemented, there is no easy way to have gnome-keyring
secrets/pkcs11 agent, whilst using gnupg/openssh agents for those
things.
These things seem to also resonate with
https:/
I'm chatting on #ubuntu-destkop about it as well, a better plan needs
to be in place for easy way to use gnome-keyring for ssh/gpg (for
simple users), but also easy way to disable gnome-keyring's ssh/gpg
agents when it's not appropriate (advanced keys, certs, smartcards,
etc).
Ideally gnome-keyring would implement support for all of those....
--
Regards,
Dimitri.
Mike Berkley (mike-berkley) wrote : | #6 |
The ssh key breakage is worse than not handling certain key types. If the user has ECDSA key, then "ssh-add" will fail to add ANY keys, including RSA and DSA.
Do we really need the "acroread" of security key agents, with so many features that none of it is reliably secure?
Pascal de Bruijn (pmjdebruijn) wrote : | #7 |
This issue isn't about whether gnome-keyring is useful or not.
But there are indeed many reasons for not wanting to use it for anything but secret store indeed, some as listed by Dmitri.
The fact that gnome-keyring doesn't implement some of these features is rather inherent to the process, where either SSH or GPG need to advance, before GNOME is in a position to follow them. Resulting in natural "lag". The fact that GNOME Keyring is only a small part of GNOME doesn't make it any better with regard to prioritization.
The fact that GNOME (Keyring) is a usability focused project is indeed a valid reason to prefer the real ssh-agent or gpg-agent as they are security focussed projects and presumably should be more trustworthy.
As for the remark about pkcs10, I'm not sure that actually being used by anything. The main use-case for it seems to be Firefox/Thunderbird which use NSS, which doesn't seem to be hooked up to GNOME Keyring's PKCS10 component by default.
Regardless of defaults, if I understand well, the following will revert to the old behavior:
echo manual > /etc/xdg/
Allowing any user to disable to individual services like so:
echo 'X-GNOME-
echo 'X-GNOME-
echo 'X-GNOME-
Changed in gnome-keyring (Ubuntu): | |
status: | Won't Fix → Incomplete |
status: | Incomplete → In Progress |
description: | updated |
Dimitri John Ledkov (xnox) wrote : | #8 |
Meh, i've looked more into this, and I'm still annoyed.
I've tried to use gpg smartcard by default for both gpg signing/encryption and ssh authentication and it's harder than it should be.
Thus I'm gonna flip "NoDisplay=true" keys on gpg/ssh components such that one can toggle those off in the UI.
Split the gpg/ssh components from the default upstart job, and make those be sensitive on X-GNOME-
The net effect should be that if one disables the gnome-keyring-
Dimitri John Ledkov (xnox) wrote : | #9 |
tags: | added: patch |
Launchpad Janitor (janitor) wrote : | #10 |
This bug was fixed in the package gnome-keyring - 3.10.1-1ubuntu9
---------------
gnome-keyring (3.10.1-1ubuntu9) vivid; urgency=medium
* Show gnome-keyring-gpg & gnome-keyring-ssh in the startup application,
for ease of disabling.
* Make upstart jobs to start gnome-keyring gpg/ssh components, if the
startup applications have not been disabled as per above.
* If the upstart jobs are disabled, default stock gpg-agent & ssh-agent
will be used.
* This should resolve LP: #1387303.
-- Dimitri John Ledkov <email address hidden> Sun, 23 Nov 2014 23:43:52 +0000
Changed in gnome-keyring (Ubuntu Vivid): | |
status: | In Progress → Fix Released |
NightShade (tim-night-shade) wrote : | #11 |
Installing the package from Vivid on my Utopic desktop has fixed my problems with my Yubikey neo acting as a smart card, thanks.
Dimitri John Ledkov (xnox) wrote : | #12 |
On 15 January 2015 at 13:26, NightShade <email address hidden> wrote:
> Installing the package from Vivid on my Utopic desktop has fixed my
> problems with my Yubikey neo acting as a smart card, thanks.
>
Thanks. I'll prepare SRUs into utopic & trusty then.
--
Regards,
Dimitri.
Launchpad Janitor (janitor) wrote : | #13 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in gnome-keyring (Ubuntu Trusty): | |
status: | New → Confirmed |
Changed in gnome-keyring (Ubuntu Utopic): | |
status: | New → Confirmed |
description: | updated |
Changed in gnome-keyring (Ubuntu Trusty): | |
status: | Confirmed → In Progress |
Changed in gnome-keyring (Ubuntu Utopic): | |
status: | Confirmed → In Progress |
neagix (neagix) wrote : | #15 |
As per my other comment: https:/
Please consider also merging this script: https:/
Hello Pascal, or anyone else affected,
Accepted gnome-keyring into utopic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
Changed in gnome-keyring (Ubuntu Utopic): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed |
Changed in gnome-keyring (Ubuntu Trusty): | |
status: | In Progress → Fix Committed |
Brian Murray (brian-murray) wrote : | #17 |
Hello Pascal, or anyone else affected,
Accepted gnome-keyring into trusty-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
Ross Younger (crazyscot) wrote : | #18 |
gnome-keyring 3.10.1-1ubuntu4.2 fixed my instance of this issue on trusty (#1388259 - ECDSA keys not working).
Many thanks!
tags: |
added: verification-done removed: verification-needed |
tags: |
added: verification-needed removed: verification-done |
Ross Younger (crazyscot) wrote : | #19 |
I tagged this bug as verification-done, but had second thoughts: I've only tested on trusty, not utopic, and it would be good to have confirmation from somebody who uses OpenPGP smartcards.
tags: | added: verification-done-trusty verification-needed-utopic |
description: | updated |
description: | updated |
tags: | removed: verification-needed |
Launchpad Janitor (janitor) wrote : | #20 |
This bug was fixed in the package gnome-keyring - 3.10.1-1ubuntu4.2
---------------
gnome-keyring (3.10.1-1ubuntu4.2) trusty; urgency=medium
* Backport changes in user session gnome-keyring jobs up to
3.14.
* Enable gnome-keyring ssh and gpg daemons to appear in "Startup
Applications".
* Split gnome-keyring user session job into ssh, gpg, and keyring jobs.
* Make sure ssh/gpg keyring jobs only start, if not disabled in gui or
with usptart override.
* This thus allows to use stock ssh/gpg agents as provided by respective
upstreams.
-- Dimitri John Ledkov <email address hidden> Fri, 23 Jan 2015 18:45:16 +0000
Changed in gnome-keyring (Ubuntu Trusty): | |
status: | Fix Committed → Fix Released |
Adam Conrad (adconrad) wrote : Update Released | #21 |
The verification of the Stable Release Update for gnome-keyring has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
tags: | added: regression-update |
Andy Brody (abrody) wrote : | #22 |
This seems to fix the problem on utopic with 3.10.1-1ubuntu7.1
tags: |
added: verification-done-utopic removed: verification-needed-utopic |
Launchpad Janitor (janitor) wrote : | #23 |
This bug was fixed in the package gnome-keyring - 3.10.1-1ubuntu7.1
---------------
gnome-keyring (3.10.1-1ubuntu7.1) utopic; urgency=medium
* Backport changes in user session gnome-keyring jobs up to
3.
* Enable gnome-keyring ssh and gpg daemons to appear in "Startup
Applications".
* Split gnome-keyring user session job into ssh, gpg, and keyring jobs.
* Make sure ssh/gpg keyring jobs only start, if not disabled in gui or
with usptart override.
* This thus allows to use stock ssh/gpg agents as provided by respective
upstreams.
-- Dimitri John Ledkov <email address hidden> Fri, 23 Jan 2015 19:27:42 +0000
Changed in gnome-keyring (Ubuntu Utopic): | |
status: | Fix Committed → Fix Released |
Charles Baylis (cbaylis) wrote : | #24 |
I can confirm that the "GNOME Keyring SSH Agent" entry is ticked in the startup applications window. A little more experimentation has provided more insight.
Starting with gnome-keyring 3.10.1-1ubuntu4.1, and continuing into 3.10.1-1ubuntu4.2, the ssh-agent only affects some processes started within a user session. The last working version was gnome-keyring 3.10.1-1ubuntu4
To demonstrate:
press Windows key, type xterm<enter>. In the new terminal window type 'echo $SSH_AUTH_SOCK'. Result, as expected, is something like /run/user/
Now, press Alt-F2, type xterm<enter>. n the new terminal window type 'echo $SSH_AUTH_SOCK'. This results in an empty line - when started in this manner the terminal does not have access to the SSH agent.
I expect processes to have the SSH_AUTH_SOCK variable defined regardless of the method used to start them
Dimitri John Ledkov (xnox) wrote : | #25 |
@cbaylis
This is indeed true. See bug #1433013. At the moment as a work-around I suggest to use:
Super -> type xterm -> hit enter
As that has the right environment. Alt-F2 does not have the right env at the moment.
Gunnar Thielebein (lorem-ipsum) wrote : | #26 |
I can confirm that this issue still exists in vivid with gnome-keyring 3.16.0-0ubuntu1.
If terminal is opened via Alt + F2 session does not contain SSH_AUTH_SOCK env. Workaround is to use Alt + Strg + T.
Dimitri John Ledkov (xnox) wrote : | #27 |
alt-f2 bug is bug #1433013 not this one. and has a much wider scope than just gnome-keyring.
Changed in gnome-keyring (Ubuntu Trusty): | |
importance: | Undecided → Wishlist |
Changed in gnome-keyring (Ubuntu Utopic): | |
importance: | Undecided → Wishlist |
xdg-autostart .desktop file is used in sessions that are not upstart managed.
upstart user session jobs are used in upstart managed sessions, e.g. unity.
to disable a job, echo "manual" into an override file (just like with any other upstart jobs)
One can override upstart user session jobs, on per-user, per-session, or system-wide.
e.g. upstart/ gnome-keyring. override xdg-ubuntu/ upstart/ gnome-keyring. override upstart/ gnome-keyring. override
echo manual > /etc/xdg/
echo manual > /etc/xdg/
echo manual > ~/.config/
See man 5 init and the upstart cookbook.
The default agent for unity session is gnome-keyring, however that was not the case in 14.04 until an update was released to resolve bug https:/ /bugs.launchpad .net/ubuntu/ +source/ gnome-keyring/ +bug/1271591
If you wish to use any other agents, use manual override to disable gnome-keyring job and provide your own upstart jobs for other agents, similar to how the gnome-keyring job is defined.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS