regression: gnome-keyring components can't be disabled anymore

[Pascal de Bruijn]

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/upstart/gnome-keyring-ssh.override)

=====

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-Autostart-enabled=false' >> /etc/xdg/autostart/gnome-keyring-gpg.desktop

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/upstart/sessions/gnome-keyring.conf

So it seems the /etc/xdg/autostart/gnome-keyring files are either being ignored, or the started process is supplanted by the process started by the upstart session config.

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/autostart/gnome-keyring-*.desktop files to prevent confusion as mentioned above. And in my opinion a mechanism should be provided so users can control which gnome-keyring components '--components=pkcs11,secrets,ssh,gpg' are activated using some configuration file in /etc, as files in /usr aren't meant to be user edited.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: gnome-keyring 3.10.1-1ubuntu4.1
ProcVersionSignature: Ubuntu 3.13.0-39.66-generic 3.13.11.8
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..etc.xdg.autostart.gnome.keyring.gpg.desktop: 2014-04-09T19:49:03.884840

[Dimitri John Ledkov (xnox)]

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.
echo manual > /etc/xdg/upstart/gnome-keyring.override
echo manual > /etc/xdg/xdg-ubuntu/upstart/gnome-keyring.override
echo manual > ~/.config/upstart/gnome-keyring.override

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

[Dimitri John Ledkov (xnox)]

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)]

This same bug affects ssh keys, since gnome-keyring cannot handle ECDSA keys.

[Dimitri John Ledkov (xnox)]

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_INFO=/tmp/gpg-cSjth3/S.gpg-agent:2791:1
GNOME_KEYRING_CONTROL=/run/user/1000/keyring-BCPZie
SSH_AUTH_SOCK=/run/user/1000/keyring-BCPZie/ssh
GNOME_KEYRING_PID=2567

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://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/884856

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)]

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)]

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/upstart/gnome-keyring.override

Allowing any user to disable to individual services like so:
echo 'X-GNOME-Autostart-enabled=false' >> /etc/xdg/autostart/gnome-keyring-gpg.desktop
echo 'X-GNOME-Autostart-enabled=false' >> /etc/xdg/autostart/gnome-keyring-ssh.desktop
echo 'X-GNOME-Autostart-enabled=false' >> /etc/xdg/autostart/gnome-keyring-pkcs10.desktop

[Dimitri John Ledkov (xnox)]

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-Autostart-enabled=false in the matching xdg autostart keys (either global /etc/xdg/autostart/gnome-keyring-ssh|gpg.desktop or per user ~/.config/autostart/gnome-keyring-ssh|gpg.desktop)

The net effect should be that if one disables the gnome-keyring-ssh.desktop via UI, or any standard way, a standard ssh-agent will be used. Ditto with gnome-keyring-gpg.desktop.

[Launchpad Janitor (janitor)]

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

[NightShade (tim-night-shade)]

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)]

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)]

Status changed to 'Confirmed' because the bug affects multiple users.

[neagix (neagix)]

As per my other comment: https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1257706/comments/7

Please consider also merging this script: https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1257706/+attachment/4305003/+files/91-custom-gpg-agent

[Brian Murray (brian-murray)]

Hello Pascal, or anyone else affected,

Accepted gnome-keyring into utopic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnome-keyring/3.10.1-1ubuntu7.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Pascal, or anyone else affected,

Accepted gnome-keyring into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnome-keyring/3.10.1-1ubuntu4.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Ross Younger (crazyscot)]

gnome-keyring 3.10.1-1ubuntu4.2 fixed my instance of this issue on trusty (#1388259 - ECDSA keys not working).
Many thanks!

[Ross Younger (crazyscot)]

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.

[Launchpad Janitor (janitor)]

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.0-1ubuntu2. (LP: #1387303)
  * 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

[Adam Conrad (adconrad)]

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.

[Andy Brody (abrody)]

This seems to fix the problem on utopic with 3.10.1-1ubuntu7.1

[Launchpad Janitor (janitor)]

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.14.0-1ubuntu2. (LP: #1387303)
   * 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

[Charles Baylis (cbaylis)]

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/1000/keyring-mm1fAl/ssh

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)]

@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)]

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)]

alt-f2 bug is bug #1433013 not this one. and has a much wider scope than just gnome-keyring.