[tor-bugs] #9308 [Firefox Patch Issues]: JavaScript's BrowserFeedWriter() leaks installation paths on OS X and Windows

[Tor Bug Tracker & Wiki]

#9308: JavaScript's BrowserFeedWriter() leaks installation paths on OS X and
Windows
-------------------------------------+-------------------------------------
     Reporter:  cypherpunks          |      Owner:  mikeperry
         Type:  defect               |     Status:  needs_revision
     Priority:  critical             |  Milestone:
    Component:  Firefox Patch        |    Version:
  Issues                             |   Keywords:  tbb-fingerprinting,
   Resolution:                       |  tbb-easy, interview
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+-------------------------------------

Comment (by arthuredelstein):

 Replying to [comment:29 gk]:
 > Replying to [comment:28 arthuredelstein]:
 > > Replying to [comment:26 gk]:
 > > > What about Mike's idea of doing a python stub that is doing the pre-
 compilation?
 > >
 > > Maybe I'm not understanding this suggestion. I don't see how python
 can compile JavaScript, unless we write our own JS compiler ;). I'm not an
 expert on this startup cache, but from my googlings, it seems these files
 are SpiderMonkey-compatible bytecode.
 >
 > Yes. Frankly, I am not sure what the xpcshell binary is doing under the
 hood. My guess (and maybe Mike's) was that it is "just" calling some other
 code that does the hard work (i.e. get the js into bytecode). And maybe
 replacing the xpcshell binary with some Python code that is just calling
 the other code as well might have worked.

 My experiments showed that the xpcshell is using various C++ libraries
 (such as, presumable, the JS compiler and runtime) that are also used
 by Firefox. The C++ source for this code is part of the Mozilla build.
 So that's why it would be necessary to build tor-browser.git natively
 in order to compile the JavaScript: not just to build the xpcshell
 binary, but also to build all the needed libraries.

 > > > And what about compiling those .js files once and ship them as
 resources via the gitian versions files?
 > >
 > > Yes, I think that absolutely can work, but don't we then need a way to
 verify the integrity of those binary files on the build machine? Is there
 currently a mechanism for doing that?
 >
 > Yes, having > 1 people build the code on different machines (as we
 already do now) and make sure the sha256sums match.
 >
 > > Would checking the binaries into tor-browser.git or tor-brower-
 bundle.git and relying on git's hashing strategy be acceptable?
 >
 > Well, I think we would put it on a mirror and download it when fetching
 the build prerequisites (there are mirror URLs in the fetch-inputs.sh we
 already use). Then we could fiddle with the bundle descriptors and put
 them manually into the omni.ja files.


 That will definitely work. A mirror alone is dangerous, though, because
 anyone building TBB would need to trust the binary files. So for the
 integrity check, it seems we need
 two paths for getting the binary .js files -- one locally, where the
 files are borrowed from the linux build, and one from a mirror, for
 the case when we don't have time to run the linux build. Then the
 resulting TB builds can be compared to make sure nothing nefarious has
 happened. Or can you see a simpler way to verify the binary files'
 integrity?

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