[PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default.
wk at gnupg.org
Fri Sep 16 08:09:06 CEST 2016
On Thu, 15 Sep 2016 17:50, dkg at fifthhorseman.net said:
> these sockets by anyone by default. For SSH, the user will need to set
> SSH_AUTH_SOCK explicitly to point to this location, *and* the keys must
> be listed in ~/.gnupg/sshcontrol. For the other sockets, the user will
ssh-add adds new keys and updates sshcontrol. Manually updating
sshcontrol is only required to use keys which were not initially
created for ssh.
> If ssh auto-starts gpg-agent, then it should absolutely start it up with
> the ssh-socket enabled, no? I suspect that if anyone is going to find
No, it would first check whether the support has been enabled.
>> ssh is and want to use it, are all able to click on
>> "enable-ssh-support" in some GnuPG GUI or add it to gpg-agent.conf.
> *and* then point their ssh clients at it.
As long as we need to use the clumsy envvar thing in ssh.
> provided by the standard socket, right? What's the risk of exposing it
> given that the standard socket is already exposed?
It used to be common practice in Debian to only open ports which are
really needed. Why should gpg-agent open a port (or here a socket)
which is in general not required. Adding two extra doors makes it
easier to break into a house.
Other reasons are extra running code, more strange bug reports, and the
user might want to use a different file name for the socket than what
gpg-agent defaults to.
> flexible, and secure. Actually listening on ssh and extra sockets by
> default doesn't seem to violate those goals.
I am not convinced.
As I said, when we notice that --extra-socket is in real use we can
change the defaults easily. But right now it is too esoteric.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 162 bytes
Desc: not available
More information about the Gnupg-devel