Comment 5 for bug 1387303

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.