Patch GPG to support SOCKS proxies

added component::archived/general owner::mikeperry priority::medium resolution::fixed severity::normal status::closed type::defect labels

Is GPG actually in our bundles?

We have a libtorsocks that ioerror adapted from torsocks. We maybe able to use some of its functionality in a patch to GPG.

Replying to mikeperry:

Is GPG actually in our bundles?

No, but some users torify GPG using its HTTP proxy support, and Windows users who need to torify GPG can't use torsocks for that purpose.

We have a libtorsocks that ioerror adapted from torsocks. We maybe able to use some of its functionality in a patch to GPG.

The licenses are compatible.

Also, gnupg's network code really isn't bad at all, and there isn't much of it: if we want to go via a patch route, it doesn't look as if it would be too hard.

That's great. The reality is this shouldn't block us from making releases without Polipo though. There are probably 2 people who use the gpg command line on Windows with Tor. It is almost certain that the other 7 GPG users on Windows use a GUI and would never even know to set proxy settings of any sort for the execution of gpg itself.

Trac:
Cc: N/A to tor@flamsmark.com

At best this is a Torify shortcoming.. Certainly not a Tor bundles issue.

Trac:
Parent: #2844 (closed) to N/A
Component: Tor bundles/installation to Torify
Resolution: N/A to not a bug
Status: new to closed

Trac:
Resolution: not a bug to N/A
Status: closed to reopened

As pointed out by David Shaw you can use socks proxies with gpg on non-Windows systems if your curl version is >= 7.21.7

http://lists.gnupg.org/pipermail/gnupg-devel/2012-September/026923.html

See also #6940 (closed)

Do we want to add a patch that gives a specific command line argument or do we just settle for the way it is done and call it a day?

Bad news - if the GPG client has no SOCKS5 support and you try to use the SOCKS5 support it will fail badly.

It has DNS leaks:

DNS	Standard query SRV _pgpkey-http._tcp.pool.sks-keyservers.net
DNS	Standard query response, No such name

So in a sense we have gpg support for SOCKS proxies but versions that don't have it won't fail before harming users.

We can probably hack gpg to try connect to a bare IP and if it fails to connect with that error, we could take that as a hint that gpg isn't safe to use.

I don't think this is a solved problem on Windows.

On Mac OS X 10.5.8, I see that the popular gpg package ( https://www.gpgtools.org ) links against libcurl/7.16.3 and so it does not work. I suspect that other versions of Mac OS X will have other versions of libcurl. A version table would be nice - does anyone have one offhand?

Cleanest imaginable solution: #6060 (moved) add http proxy support to Tor

Can you do it? Can perhaps portions of privoxy or poliop source code be used?

Trac:
Cc: tor@flamsmark.com to tor@flamsmark.com, adrelanos@riseup.net

Replying to ioerror:

Bad news - if the GPG client has no SOCKS5 support and you try to use the SOCKS5 support it will fail badly.

This means we can not statically configure gpg to use socks5 proxies (in torbirdy).

Can we build an autodetection for socks support and change enigmail's config acordingly?

enable socks5 proxy in enigmail's gpg options iff we have socks support
do not set the socks proxy if we have no support for it (set a non-existing http proxy to fail secure)

I've heard that curl Version 7.21.4 is the version included in Mac OS X 10.8 - so that would likely be safe if it is properly used by gpgtools.

It appears that the versions of curl are as follows: Mac OS X 10.8.x - 7.24.0 Mac OS X 10.7.4 - 7.21.4 Mac OS X 10.6 - 7.19.0 Mac OS X 10.5 - 7.16.2 Mac OS X 10.4 (intel) - 7.13.0

I'm guessing that information based on extracting version numbers from Apple's developer man page website. Painful and likely error prone.

If that is correct, I guess no version of gpg on Mac OS X 10.4.x -> 10.7.x would be likely to support such a proxy. It may be the case that Mac OS X 10.8.x has a newer curl release but I'm not sure.

Replying to tagnaq:

Replying to ioerror:

Bad news - if the GPG client has no SOCKS5 support and you try to use the SOCKS5 support it will fail badly.

This means we can not statically configure gpg to use socks5 proxies (in torbirdy).

I'm not sure of that but I understand the caution. I think that we just need to detect this (common) case and do something smart.

Can we build an autodetection for socks support and change enigmail's config acordingly?

enable socks5 proxy in enigmail's gpg options iff we have socks support

Sounds like a bug for enigmail - want to open it? :)

do not set the socks proxy if we have no support for it (set a non-existing http proxy to fail secure)

That seems OK, I guess.

Well - things just appear to get worse and worse here - I see the same SRV DNS leaks (DNS Standard query SRV _pgpkey-http._tcp.pool.sks-keyservers.net) even when we use an HTTP proxy. See this bug for how I setup a local HTTP proxy with shim: https://trac.torproject.org/projects/tor/ticket/6060#comment:8

I thought that perhaps if we set '--no-auto-key-locate' - we would not leak DNS. It still leaks DNS as far as I am able to tell. It looks like the configuration option '--disable-dns-srv' at compile time may be the next best hope.

tagnaq - can you confirm that you also leak DNS as expected, even when using SOCKS5 with the socks-hostname url scheme?

Patch GPG to support SOCKS proxies

Child items ...

Activity