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

Werner Koch wk at gnupg.org
Mon Sep 19 18:16:12 CEST 2016

On Mon, 19 Sep 2016 12:21, justus at g10code.com said:

> 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

Hey, don't say this.  As long as we make it generic enough I see no
sound reason not to get this upstream.

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

As I said, it is another open door.  It is the same as running portmap
despite that you won't use it.  Unfortunately, Debian seems to enable
portmap these days by default.  (Debian is not anymore the only distro
which could be called secure by default :-()

> use the option to specify a different name.  I was carefull not to break
> anyones setup.

I have not see a way to disable this feature at all.  This be a hard
requirement.  Actually this is not easy to do if you also want gpgconf
be abale to modify it.  However, I would except the use of "/dev/null"
as flag to disable the socket.

> away using some configuration option.  And agent-forwarding isn't an
> esoteric use case.

It is pretty new; it works since January 2015 - and it is only possible
since the release of OpenBSD 6.7 (?) which back then was not even in

> I believe that ssh support and the restricted socket for
> agent-forwarding are awesome features, please don't hide features in the

Agreed.  Well, your change would not have helped you either.  Adding
enable-ssh-socket to gpg-agent.conf is the smallest part of the stroy.
The more complicated thing is the external setup and the new concept.

> And we enabled loopback pinentry by default so that Mailpile users don't
> have to do that manually.

I am still not convinced that this was a good idea ;-)

> 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

Yes, the tools should do that.  gpgconf provides an easy way to change
the configuraions.  Tools are already chnaging gpg'c configuraion behind
the back of the user.

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

Yes, they should stick to that, for example to use the Pinentry by
default.  If they want something else, they need to tweak things.

Anyway, if you provide a new patch with a way for gpgconf to disable the
new default and with shorter socket names (e.g. change
"S.gpg-agent.restricted" to "S.gpg-agent.xtr" or ".extra"), it would be
hard for me to reject such a patch.



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/20160919/8b8b3dc8/attachment.sig>

More information about the Gnupg-devel mailing list