[tor-bugs] #21830 [Applications/Tor Browser]: Copying large text from web console leaks to /tmp

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Jul 21 01:04:07 UTC 2017


#21830: Copying large text from web console leaks to /tmp
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  neillm
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-disk-leak,                       |  Actual Points:
  TorBrowserTeam201707R                          |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by neillm):

 Replying to [comment:12 arthuredelstein]:
 > Replying to [comment:8 neillm]:
 >
 > > This patch has been applied to tor-browser-52.2.0esr-7.0-1-build1 and
 tested on Ubuntu 16.04.2 LTS.
 >
 > Thanks -- I built with the patch and it worked as described. But the
 `aContext` argument of `nsTransferable::Init()` appears to have only one
 purpose, which is to check for PBM state. So I wonder if you think it
 would make sense to change the signature to `nsTransferable::Init(bool
 isPrivateBrowsingMode)`? Then perhaps the callers could be modified to
 provide PBM state, assuming they have that information:
 >
 > https://dxr.mozilla.org/mozilla-
 central/search?q=%2Bcallers%3A%22nsTransferable%3A%3AInit%28nsILoadContext+%2A%29%22
 >
 > (I'm not sure if this is a practical idea or not, so feel free to
 disagree.)

 It's a good idea, but I think practically speaking, it would be much more
 complicated.  The reason I say that is because all of those times where
 the nsTransferable is initialized without a context, it's because we
 (likely) don't actually know at that point if it's a private browsing mode
 or not.  After all, if we did, we could have loaded it with the context to
 begin with (although perhaps there are some lazy cases where it could be
 used and isn't).

 So for those remaining cases (without the context), while we may be able
 to load the preference default as this patch does, we would have to do it
 in a lot more places before we know what boolean to pass in to the Init
 (if modified).  Does that make sense?

 Other than that, you're right, it appears that it's only used for that
 reason at this point.  Assuming there are no other future uses of that
 context by the transferable, refactoring could work.

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


More information about the tor-bugs mailing list