intrigeri:
> billingsciences89@??? wrote (16 Sep 2015 18:30:51 GMT) :
>> > It seem that after the total removal of Polipo (Tails 1.3 and up [0]) Go's
>> > "go get" command does not work anymore in Tails ; giving "unrecognized
>> > import path" is supposedly a notice about refusing to connect [1].
>> >
>> > Does the Tails team plan to support "go get" in the same way as "git
>> > clone" [2]?
>
> Please try prefixing such commands with torsocks or (better) look for
> a way to configure the go command to use a SOCKS5 proxy. Even if we
> don't ship the golang compiler, we could ship a config file to address
> that problem.
Some comments about the problems of using "go get" in Tails.
1. Leif originally wrote: "I think torsocks doesn't work because go get
needs to send an HTTPS(fallback to HTTP) request with ?go-get=1 for any
imports from domains without hardcoded behavior (as described in the go
get documentation) ...".
The important part is the "without hardcoded behaviour".
> go get github.com/golang/example/hello
works fine, because the go tools "knows" about the github.com domain and
translates the request into
> git clone https://github.com/golang/example/hello.
The request
> go get robpike.io/ivy
instead won't work, because the go tool needs to send a HTTPS request to
find out the URL of the Git repository to clone from.
If that package is *already* installed and we do an update using "go get
-u", then the go tool can again translate into a "git upadate ...", that
will succeed because Git works in Tails.
2. I believe Torsocks won't work with go tools. There are two problems:
(1) Go has two address resolvers: One written in Go sends DNS requests
directly, the other using the C library's getaddrinfo(). The native Go
version is the default on Linux, but in recent releases of Go one can use
> export GODEBUG=netdns=cgo
to force the use of the C based version. But then (2) Go makes a direct
syscall[1] instead of using the connect(2) library function to initiate
a TCP/IP connection. Thus torsocks LD_PRELOAD can't intercept the
function call.
3. Both the direct DNS requests and the direct syscall make sense from
the point of view of Go and won't be changed. There is a very old
ticket[2] about using the connect() function in case that LD_PRELOAD is
set, but I am skeptical that this will every be implemented.
4. The go tool is just a convenient way to install and compile code, but
one in not forced to use the tool. One can either do go get's work
manually, as in [3], or maintain a fork of the go tool, that uses Tor by
default. The latter is what I am planning to do, if such a thing doesn't
materializes on its own. Maybe one could even find a way to incorporate
onion addresses into Go's package naming conventions.
Cheers!
[1]
https://github.com/golang/go/blob/master/src/syscall/syscall_linux_386.go#L265
[2]
https://github.com/golang/go/issues/3744
[3]
https://github.com/agl/xmpp-client/issues/82#issuecomment-77586240
