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

[Tor Bug Tracker & Wiki]

#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):

 Replying to [comment:11 alexcrichton]:
 > *.bc.z files in archives are a semi-custom compression format for LLVM
 IR files (we really should just use `*.gz`...) The `*.o` files are the
 codegen'd versions of those. Given that the LLVM IR is changing that means
 one of a few things:
 >
 > * Something in the source is changing, causing different IR to be
 produced
 > * Rustc is non-deterministically producing IR
 > * LLVM is non-deterministically optimizing IR
 >
 > It's great to narrow this down to just one crate! I've found that
 minimization tends to make bisection much much easier. Given that this is
 related to rlibs this probably isn't related to LTO since those object
 files are all pre-LTO. In terms of minimizing this further, are the object
 files similarly named? If so are there "obvious diffs" within them?
 Otherwise if the object files have completely different names that'd be
 more worrisome!

 The object files have the same name but alas there are no obvious diffs.
 The diff file I am getting after running

 `diff -u <(xxd 1/style-73fdc83c00a82101.style.dqyyj3ie-cgu.0.rcgu.o) <(xxd
 2/style-73fdc83c00a82101.style.dqyyj3ie-cgu.0.rcgu.o)`

 is 300 MiB (!) large and skimming it nothing really sticks out.

 One thing that's been interesting during all this bisecting is that there
 is not a variety of different results one can get when compiling the style
 crate. In fact, there are only two different .rlib files I've got so far
 per tested Rust version (if the Rust version contained the reproducibility
 bug).

 > If you can I'd recommend whacking away at the `style` crate's source
 code, deleting swaths of it as you can to see if you can get non-
 reproducible builds on one compiler. Basically at this point it's just a
 game of minimization to find the bug. If you've got a set of semi-
 digestable instructions to reproduce where you're at as well, we could try
 to pass this around and see if others can help chip in too to diagnose the
 bug.

 Thanks. boklm has been working on minimizing the code that gets built when
 building the style crate. He might have some update on that.

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