[tor-bugs] #32053 [Applications/Tor Browser]: macOS bundles for Tor Browser 9.0a8 are not reproducible

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Oct 26 21:27:11 UTC 2019


#32053: macOS bundles for Tor Browser 9.0a8 are not reproducible
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:  new
 Priority:  Immediate                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Critical                             |     Resolution:
 Keywords:  TorBrowserTeam201910, tbb-9.0-must,  |  Actual Points:
  tbb-9.0-issues, tbb-regression, tbb-9.0.1-can  |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by gk):

 Okay, time to give an update here. `bug_32053_v2`
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/log/?h=bug_32053_v2) contains two commits that reduce the build
 time while still being able to reproduce the bug. First of all, I am not
 100% yet that LTO is not introducing a second reproducibility issue here
 but disabling it does not solve the bug I am hunting. It has the nice
 side-effect, though, that without LTO the build time of `libgkrust.a` goes
 down another approx. 2 minutes on my faster machine.

 I don't blow the whole obj dir away anymore. Rather, I build everything
 the first time and if it's matching I just remove `libstyle-*.rlib`. After
 a while I get different Stylo .rlib files. Keeping those .rlib files and
 trying to check whether `geckoservo` or even `gkrust` builds trigger the
 bug (by just deleting their respective artifacts and checking whether
 `libgkrust.a` changes) is negative. So, I am fairly confident that
 building Stylo is the problem here.

 That moves me to phase 2 in this exciting process: I'll start bisecting
 the Rust compiler to figure out where this bug started (while avoiding
 #26475 :) ) and I'll try to save even a bit more build time by not caring
 about `libgkrust.a` but doing the SHA-256 check against the Stylo .rlib
 directly.

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


More information about the tor-bugs mailing list