[tbb-bugs] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Sep 23 10:38:23 UTC 2019
#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
More information about the tbb-bugs
mailing list