Go ldflags should set static build ID

The Go linker includes a build ID by default, which is sometimes nonreproducible. This should be fixed by changing the value of ldflags in tor-browser-build from the current '-s' to '-s -buildid=' (which sets the build ID to an empty string).

added TorBrowserTeamTriaged component::applications/tor browser owner::tbb-team priority::medium resolution::worksforme severity::normal status::closed tbb-rbm type::defect labels

Let me know if you'd like me to code up a patch for this.

proof?

Interesting. I wonder why we have not hit that issue yet. I am fine adding that part if it really helps.

Trac:
Keywords: N/A deleted, tbb-rbm added

Interesting. I wonder why we have not hit that issue yet.

I'm not 100% sure why Tor hasn't had problems with it; I can confirm that Namecoin is definitely having problems with it when using Tor's rbm projects; see https://github.com/namecoin/ncdns-repro/issues/57 . I can think of 2 plausible explanations for this:

1. Namecoin exercises cgo-related code paths in more interesting ways than Tor does, so maybe the build ID happens to be reproducible in Tor's setup when not using cgo in the ways that Namecoin does.
2. Namecoin uses go install to build the final binaries, whereas Tor uses go install only to build libraries and go build to build the final binaries, so maybe the build ID happens to be reproducible in Tor's setup when using go build, and possibly either the build ID isn't embedded into libraries at all, or no one has checked the libraries for reproducibility issues since the final executable output is still reproducible.

That said, the build ID is almost definitely nonreproducible even in Tor's usage when comparing rbm-built binaries to non-rbm-built binaries, because the build ID is partially dependent on the build path, which is consistent inside rbm but won't be consistent elsewhere. So, fixing this is useful to make it easier to audit the reproducibility of Tor's binaries via build platforms other than rbm (in addition to the fact that it seems to be needed for downstream projects like Namecoin to be reproducible at all, for some reason).

Fixing this is blocked by #30334 (moved), as a patch for this ticket would probably touch the same code as what's being touched by #30334 (moved), so waiting for #30334 (moved) to be resolved prior to solving this one would avoid merge conflicts.

It looks like this bug has been fixed in Go 1.13.3, see https://github.com/golang/go/issues/34326 . So, if tor-browser-build upgrades to Go 1.13.3 or higher, then this ticket could be closed.

Further investigation seems to support my above hypothesis that Namecoin is running into this because we exercise cgo-related code paths that Tor currently doesn't. (Specifically, Namecoin's executable Go projects are reproducible within rbm, while our Go project that produces a C ABI shared library exposes nonreproducibility in the build ID when built in rbm.) Usage of go install versus go build doesn't seem to have any effect on whether the build ID is reproducible. In any event, fixing this is still a good idea for Tor since it improves reproducibility between rbm and non-rbm build usage.

Correction to the above: what I said above is accurate for GNU/Linux targets. For macOS targets, even some of Namecoin's executable Go projects have nonreproducible build ID's with current tor-browser-build; setting a static build ID as described in this ticket makes Namecoin's executable Go projects reproducible for macOS targets. It's not clear to me why macOS behaves differently from GNU/Linux; nor is it clear to me why Tor hasn't run into this.

We may upgrade to Go 1.13 before landing this (see #32027 (moved)).

Trac:
Keywords: N/A deleted, TorBrowserTeamTriaged added

We did so recently, closing.

Trac:
Status: new to closed
Resolution: N/A to worksforme

closed

moved to tpo/applications/tor-browser#31691 (closed)