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

Re: [tor-bugs] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68



#30429: Rebase Tor Browser patches for Firefox ESR 68
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  task                                 |         Status:
                                                 |  needs_revision
 Priority:  Very High                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,        |  Actual Points:
  TorBrowserTeam201909                           |
Parent ID:                                       |         Points:  1
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor44-can
-------------------------------------------------+-------------------------
Changes (by gk):

 * keywords:  ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R =>
     ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909
 * status:  needs_review => needs_revision


Comment:

 So, it seems we have two new checks for "is this a .onion and should we
 treat this as trustworthy?". Could we use the one that actually is
 available in the tree instead
 (`nsMixedContentBlocker::IsPotentiallyTrustworthyOnion()`)? That would at
 least make in the `nsDocShell` sense given the mixed content context your
 changes are in. But in the others as well I feel. We should adapt
 `URICanBeConsideredSecure()`, too (which had the .onion check already. Not
 sure what *I* saw while reviewing previously ;) ).
 {{{
    // If the security state is STATE_IS_INSECURE, the TLS handshake never
    // completed. Don't set any further state.
 }}}
 Does not make much sense anymore with the code changes. Could you add a
 different comment explaining e.g. why we check for != INSECURE here after
 making sure there is actually a `securityInfo` available, which might not
 be obvious at first glance.

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