Re: [tor-bugs] #11671 [EFF-HTTPS Everywhere]: HTTPS Everywhere breaks http://www.theregister.co.uk/

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#11671: HTTPS Everywhere breaks http://www.theregister.co.uk/
--------------------------------------+------------------
     Reporter:  cypherpunks           |      Owner:  zyan
         Type:  defect                |     Status:  new
     Priority:  normal                |  Milestone:
    Component:  EFF-HTTPS Everywhere  |    Version:
   Resolution:                        |   Keywords:
Actual Points:                        |  Parent ID:
       Points:                        |
--------------------------------------+------------------

Comment (by cypherpunks):

 The problem is also there in SeaMonkey 2.26.1 which is based on Firefox
 29.

 The null loadContext causes an exception which then causes Firefox to stop
 processing the Javascript with the problem. In turn this causes the CSS
 not to be loaded. I've not investigated in detail, but handling the null
 pointer appears to fix the problem. Here's a proposed fix (note that I
 don't have access to diff on this Windows box so I've annotated the code
 by hand):

 {{{
   getWindowForChannel: function(channel) {
     // Obtain an nsIDOMWindow from a channel
     let loadContext;
     try {
       loadContext =
 channel.notificationCallbacks.getInterface(CI.nsILoadContext);
     } catch(e) {
       try {
         loadContext =
 channel.loadGroup.notificationCallbacks.getInterface(CI.nsILoadContext);
       } catch(e) {
         this.log(NOTE, "No loadContext for " + channel.URI.spec);
         return null;
       }
     }

     /* vvvvvvvvvvv new code starts here vvvvvvvvvv */
     if (!loadContext) {
       this.log(NOTE, "loadContext is null for " + channel.URI.spec);
       return null;
     }
     /* ^^^^^^^^^^ new code ends here ^^^^^^^^^^ */

     /* The following is line 424 that can't deal with loadContext being
 null */
     let domWin = loadContext.associatedWindow;
     if (!domWin) {
       this.log(NOTE, "failed to get DOMWin for " + channel.URI.spec);
       return null;
     }

     domWin = domWin.top;
     return domWin;
   },

 }}}
 Editing
 c:\Users\xxx\!AppData\Roaming\Mozilla\...\Profiles\xxxx.default\extensions
 \https-everywhere@xxxxxxx\components\https-everywhere.js by hand directly
 in my installation fixes the problem. That's the limit of the testing I've
 been able to do.

 I don't know how we get a null loadContext without triggering one of the
 earlier exceptions. I don't know if that's a bug in Firefox but, in any
 event, some defensive programming is probably warranted in any security
 product.

 In case it helps debug the problem, I'll note that, at the time of
 writing, www.theregister.co.uk includes CSS with the line:

 {{{
 <link rel=stylesheet type="text/css" href="/style_picker/design?e">

 }}}
 However, that's not where it ends up. The server provides a 302 Found
 response that redirects the browser (presumably just Gecko based browsers)
 to !http://www.theregister.co.uk/Design/style/design/gecko.css?e

 I have a feeling that this problem affects just some systems where I have
 !SeaMonkey installed whereas others are fine. This, in turn, suggests that
 there some other factor that interacts to cause the problem such as which
 plugins are installed or similar.

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