Immediate: patchset needed as soon as possible
Next Minor Stable Release: patchset that needs to be verified in nightly before backport
Eventually: patchset that needs to be verified in alpha before backport
No Backport (preferred): patchset for the next major stable
Emergency security update: patchset fixes CVEs, 0-days, etc
Censorship event: patchset enables censorship circumvention
Critical bug-fix: patchset fixes a bug in core-functionality
Consistency: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc
Sponsor required: patchset required for sponsor
Other: please explain
tor-browser-specific commits, new features, security backports
base-browser-specific commits, new features to be shared with
mullvad-browser, and security backports
NOTE: if your changeset includes patches to both
tor-browserplease clearly label in the change description which commits should be cherry-picked to
- NOTE: if your changeset includes patches to both
Link resolved issues with appropriate Release Prep issue for changelog generation
Request review from an applications developer depending on modified system:
NOTE: if the MR modifies multiple areas, please
/ccall the relevant reviewers (since gitlab only allows 1 reviewer)
- accessibility : henry
- android : clairehurst, dan
- build system : boklm
- extensions : ma1
- firefox internals (XUL/JS/XPCOM) : ma1
- fonts : pierov
- frontend (implementation) : henry
- frontend (review) : donuts, richard
- localization : henry, pierov
- macos : clairehurst, dan
- nightly builds : boklm
- rebases/release-prep : dan, ma1, pierov, richard
- security : ma1
- signing : boklm, richard
- updater : pierov
- misc/other : pierov, richard
- NOTE: if the MR modifies multiple areas, please
We've long had a patch that disabled speculative connections (= connections created by the parent before the content process requests them, according to the comment in the code).
The reason is that we can see that connections are actually created on the catch-all circuit or in the wrong FPD.
However, from what I understood, the speculative connection is not then used for the real requests, at least not if it doesn't match the attributes.
Still, it was right to disable it, especially for the "open a link to a new tab" case, in which it would theoretically create a connection to the "new" domain with the old circuit (even though it was possibly not used).
In practice, this might not happen, or might be disabled on the proxy (bad for MB!). Doing a proper test is difficult, because the connection will be open anyway. I've tried with a Python HTTP server, and I didn't get two requests. So, the connection might really be a TCP connection to find it already open.
Anyway, we know how to do things properly, so let's do it.
If we think this is better than the previous state, we could try uplift it very soon, to get feedback from someone who knows more about it (even though it's quite difficult to find that someone
First, I tried to see what we got when removing the old patch with the
browser.tordomainisolator.loglevel set to
It will expose all the requests.
At that point, you'll be able to see we get requests through the
--unknown-- username, that is the catch-all circuit.
Another thing you might see is that opening links in the new tab uses a connection that is tied to the opener domain, e.g.,
Requested https://example.net/ via example.org:0:...
Then, apply the new patch. No more catch all circuit, and no more links opened with the previous domain.