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

Re: [tor-bugs] #13035 [Tor Browser]: Make sure our cache isolation works with cache2

#13035: Make sure our cache isolation works with cache2
-------------------------+-------------------------------------------------
     Reporter:  gk       |      Owner:  mcs
         Type:  task     |     Status:  needs_information
     Priority:  major    |  Milestone:
    Component:  Tor      |    Version:
  Browser                |   Keywords:  ff38-esr, tbb-linkability, tbb-
   Resolution:           |  fingerprinting, TorBrowserTeam201506
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by mikeperry):

 Replying to [comment:5 mcs]:
 > I opened a new ticket for updating the automated tests (and posted a
 patch).  See #16356.
 >
 > The only remaining question that Kathy and I have for this ticket is
 whether we should patch nsHttpChannel::DoInvalidateCacheEntry() to use our
 modified (isolated) cache keys.  That would involve passing a non-empty
 string as the second parameter to cacheStorage->AsyncDoomURI() within that
 method.  This is not new code and not something we patched in the past...
 and Kathy and I do not understand the implications of not patching it.
 But it seems like the wrong key is being used there.
 >
 > Mike, what is your opinion?

 I have not dug through all of the eviction code (there sure are a lot of
 codepaths involved there), but my initial take is that since Mozilla has
 been using this same extension key to isolate caching for POST requests,
 it probably is not a serious issue to omit it, since the original code
 would have been experiencing similar problems even before our isolation
 made further use of this key...

 It is vaguely concerning, though. We should keep an eye on about:cache
 after New Identity to ensure that nothing sticks around. I think that is
 the failure mode I'm most concerned with. I suppose the next most likely
 issue is a memory leak? Again, this seems like something they should have
 seen, though..

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