[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