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

[Justus Winter]

Hello :)

I'm really keen on convincing you, so here goes :)

Werner Koch <wk at gnupg.org> writes:
>> 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.

That's a pretty big if in the first place.  I don't see how we can add
auto-start support to ssh.  Upstream won't accept such a patch, and I
don't see Debian adding a patch for that either tbh.  In any case, we
will deal with the problem when and if that arises.

>> 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.

If an attacker has access to your ~/.gnupg, she can use the
non-restricted socket anyway, so what's the harm in also enabling the
restricted socket?

> 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.

If there are bugs, then we will fix them.  Also, it is still possible to
use the option to specify a different name.  I was carefull not to break
anyones setup.

>> 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.

I don't believe any feature will see "real use" until we stop hiding it
away using some configuration option.  And agent-forwarding isn't an
esoteric use case.

~~~

I believe that ssh support and the restricted socket for
agent-forwarding are awesome features, please don't hide features in the
default configuration.  Nowadays I'm using both features, but I had not
even heard of them before I started working for GnuPG and dug deep into
the manuals.

I don't see the web socket being widely used if we need to instruct
anyone who wants to use it to tweak their gnupg configuration first.
And we enabled loopback pinentry by default so that Mailpile users don't
have to do that manually.

Another way to look at this problem is this.  GnuPG is a low-level tool,
we explicitly do not create fancy user interfaces.  Instead, we rely on
people to create awesome tools on top of GnuPG.  Any such tool that
requires additional tweaks to the GnuPG configuration either has to
change the configuration itself or ask the user to do it.  The former is
frowned upon, and the latter is a huge usability problem.  Therefore,
tools using GnuPG are essentially restricted to the set of features that
is enabled by default.


Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: </pipermail/attachments/20160919/3830f9dc/attachment.sig>