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

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

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