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.
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....
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: INFO=/tmp/ gpg-cSjth3/ S.gpg-agent: 2791:1 CONTROL= /run/user/ 1000/keyring- BCPZie SOCK=/run/ user/1000/ keyring- BCPZie/ ssh PID=2567
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 /bugs.launchpad .net/ubuntu/ +source/ gnome-keyring/ +bug/884856
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.