Opened 2 months ago

Last modified 14 hours ago

#31691 new defect

Go ldflags should set static build ID

Reported by: JeremyRand Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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).

Child Tickets

Change History (8)

comment:1 Changed 2 months ago by JeremyRand

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

comment:2 Changed 2 months ago by cypherpunks

proof?

comment:3 Changed 2 months ago by gk

Keywords: tbb-rbm added

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

comment:4 Changed 2 days ago by JeremyRand

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).

comment:5 Changed 2 days ago by JeremyRand

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

comment:6 Changed 2 days ago by JeremyRand

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.

comment:7 Changed 19 hours ago by JeremyRand

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.

comment:8 Changed 14 hours ago by JeremyRand

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.

Note: See TracTickets for help on using tickets.