intrigeri: > [email protected] 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 _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
