[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

#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:30 arthuredelstein]:
 > 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.

 :(

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

 Well, what we are currently doing (e.g. when shipping the msvcr100.dll) is
 putting the resource in question on a mirror we control and adding its
 sha256 sum to the versions files. When there is a new release we tag it
 and sign it. That model gives good enough security for the stopgap we are
 talking about here IMO. A temporary patch for tor-browser.git would be
 cleaner, though, especially as we would not need to touch tor-browser-
 bundle related things and revert the changes later when ESR 31 lands. But
 as I said, dunno how easy that is...

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9308#comment:31>
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