[PATCH GnuPG] agent: Enable restricted, browser, and ssh socket by default.

[Werner Koch]

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.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20160916/2c3ab533/attachment.sig>