Re: [tor-bugs] #32520 [Applications/Tor Browser]: Output of go project contains nonreproducible datetime values

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#32520: Output of go project contains nonreproducible datetime values
-------------------------------------------+-------------------------------
 Reporter:  JeremyRand                     |          Owner:  tbb-team
     Type:  defect                         |         Status:
                                           |  needs_information
 Priority:  Medium                         |      Milestone:
Component:  Applications/Tor Browser       |        Version:
 Severity:  Normal                         |     Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201911  |  Actual Points:
Parent ID:                                 |         Points:
 Reviewer:                                 |        Sponsor:
-------------------------------------------+-------------------------------

Comment (by JeremyRand):

 > You're saying that you compared the build artifacts of the go compiler
 from two builds and found they aren't reproducible, while the resulting
 tor browser is reproducible?

 @sysrqb yes, the Go compiler isn't building reproducibly, while the
 projects that use it as an input do build reproducibly.

 > Since the go compiler that we build is only used locally, and not
 distributed, does it matter if the build is not reproducible? Or do you
 have a different use case where this matters?

 @boklm It's certainly much less of a big deal than if the final Tor
 Browser output were nonreproducible, but there are still cases where it
 makes a difference.

 For example, let's say that Alice and Bob are trying to build Tor Browser,
 and they get different hashes for obfs4.  If they get the same hashes for
 the Go compiler, then that helps them narrow down the bug to the obfs4
 build scripts, whereas if the Go compiler isn't reproducible either, then
 they have to consider the possibility that the Go compiler's
 nondeterminism is somehow leaking into obfs4.

 As another example, if 2 different communities (let's say Tor and
 Namecoin) are both building binaries with Go, then making the Go compiler
 reproducible allows the Tor and Namecoin communities to cross-validate
 that the Go compiler is reproducible, which means more people will be
 attesting to the non-backdoored-ness of the Go compiler.  (Given that
 today there are very few people other than employees of The Tor Project
 who are trying to reproduce Tor Browser hashes, this would be a useful
 improvement.)

 As a third example, it's conceivable that some users may want to download
 binaries of the Go compiler without trusting that Google hasn't backdoored
 them; if the Go compiler can be built reproducibly, then this enables any
 3rd party to provide downloads of those reproducible binaries without
 becoming a trusted 3rd party.

 So yes, there are cases where it matters, though admittedly they are not
 as major as the standard use case of "allow 2 Tor Project employees to
 reproduce the final Tor Browser binaries", where you're correct that it
 doesn't matter.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32520#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs