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.


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:

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

These things seem to also resonate with

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,

Ideally gnome-keyring would implement support for all of those....