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

Daniel Kahn Gillmor dkg at fifthhorseman.net
Thu Sep 15 17:50:59 CEST 2016

On Thu 2016-09-15 11:22:02 -0400, Werner Koch wrote:
> On Thu, 15 Sep 2016 14:58, justus at g10code.com said:
>> This change enables the restricted, browser, and ssh socket by
>> default.  Note that in all cases, the user has to do some additional
>> configuration to her setup to make use of these features.  Therefore,
> I am strongly against such defaults.  They are not required for any
> standard GnuPG use.  In particular the ssh-agent feature should not be
> enabled without user consent.

fwiw, i think Justus' proposal is a reasonable approach.

As Justus mentions, there are safeguards in place to prevent the use of
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
need to explicitly point their tools at them as well.

> That would be a bit similar to the GKR problem we had for years.  Right,
> you need to tell ssh about this other socket.  But at some point in the
> future we may have achieved auto starting of gpg-agent by ssh and then
> the default ssh configuration would use gpg-agent - which I would
> consider hostile.

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
anything hostile, it would be some OpenSSH users finding it hostile to
auto-start gpg-agent when they didn't want it.

> OpenSSH's agent and gpg-agent use a very different architecture,
> despite that they speak the same protocol.  Those folks, who know what
> 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.

with justus' proposal, they only need to point their ssh client at the
right locatoin.

> The extra socket stuff is even more hackish and by default a software
> shall limit itself to listen for connections on the standard port and
> not on some esoteric stuff.  Iff there will eventually be a browser or
> browser extension in wide use which requires --browser-socket (and
> probably other stuff) we can re-consider the defaults.

I'm fine with leaving --browser-socket off by default (it's not even
documented), but why should we leave extra-socket off by default?
extra-socket should provide a strict subset of the functionality
provided by the standard socket, right?  What's the risk of exposing it
given that the standard socket is already exposed?

> Note that there is a feature in the queue to set a configuration options
> From a recipe file.  This will be used to configure GnuPG according to
> certain policy guidelines.  A hacker's choice profile can of course then
> be distributed along with GnuPG.

Sure, we can distribute all kinds of profiles, but most people are going
to use the default.  We should make the default capable, robust,
flexible, and secure.  Actually listening on ssh and extra sockets by
default doesn't seem to violate those goals.

Can you be more specific about what you think the problem is?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20160915/d40a3d99/attachment-0001.sig>

More information about the Gnupg-devel mailing list