Go-tools: Publish pre-built binaries to GitHub

[dominikh]

We should upload pre-built binaries for tagged releases to GitHub. That would provide some degree of redundancy (when honnef.co is down) and probably save a lot of trees by not repeatedly compiling the tools on CI systems like Travis. It would also make it easier to depend on C libraries such as Z3 in the future, which are non-trivial to build.

One could express concern about having to trust binaries built by someone else, but nobody reads the code before compiling the master branch, either :-)

Currently planned OS/arch combinations are {windows, linux, freebsd, darwin} x {x86, amd64}, but I'm happy to support more, as long as they build with the latest released version of Go.

[dmitshur]

but nobody reads the code before compiling the master branch, either :-)

FWIW, this part isn't completely true. I read over the commits that pique my interest (not all, but many) when updating go-tools via Go Package Store. I understand not everyone does that, of course.

I'm not necessarily disagreeing with your overarching statement about binaries, just pointing this out.

[dominikh]

not all, but many

It's the few that contain the backdoors ;)

[bufdev]

You can release the sha256 sums along side the released binaries to make things a little better a la https://github.com/docker/compose/releases (doesn't solve the original issue raised here but)

[dominikh]

Another issue to take into consideration is that of GOROOT. Currently, we rely fully on runtime.GOROOT(), which either uses the $GOROOT environment variable, or the GOROOT of the build chain. Most users (rightly) don't set $GOROOT, and the build machine's GOROOT is unlikely to match that of the user.

There are two options:

1. Detect GOROOT dynamically, likely by calling out to go env (iff the environment variable isn't set). Is this going to be enough? Do custom build tools like gb also have custom GOROOT handling?
2. Bundle an entire GOROOT tree in the binary itself. This has the benefit of always working and always targeting a known Go version. It would increase the size of the binaries, however, by approximately 14 MB (determined by compressing GOROOT/src with gzip).

[bufdev]

Just wondering (I could look in the code and find out but) why is GOROOT needed? I haven't heard of something similar before - generally if you build a static Golang binary, you're good to go.

Here's how I do it for example:

https://github.com/uber/prototool/blob/78e7feb37962da93adae249a7a00998503093819/Makefile#L139
https://github.com/uber/prototool/blob/78e7feb37962da93adae249a7a00998503093819/etc/bin/releasegen.sh#L34

Between those two options, the first is almost for sure preferred if GOROOT is needed.

[dominikh]

@peter-edge Our tools do static code analysis. In order to do that, they need access to the Go standard library, which resides under GOROOT. They function similarly to a Go compiler.

[bufdev]

Fair enough, forget I brought it up, not thinking much today :-)

[knweiss]

@peter-edge However, sha256 only helps to prevent data corruption. To ensure data integrity, however, you need a digital signature (created with a private key, verified with a public key) .

Something simple as e.g. signify would work much better. Usage example.

[rajveerappan]

https://github.com/dominikh/go-tools/issues/269 seems to be an issue again right now.

[dominikh]

We now have pre-built binaries hosted on GitHub.