I'm presenting a talk on Robert Nganga's behalf (he couldn't make it to C3 in person, hopefully next year) about the proxy leak mitigation work he did as part of his Outreachy internship. There will also be a workshop after the talk to get feedback on what features and functionality the Tor community wants to see added (we intend to have Namecoin fund him to continue the project). Both the talk and the workshop will be hosted by the Critical Decentralization Cluster. So, would be awesome to have some Tor people there -- especially at the workshop.
I won't have access to my GitLab account while at the Congress; I will have my travel Matrix account join the Tor Project Matrix channel, pinging me there will be the easiest way to reach me. Or you can just walk over to the Critical Decentralization Cluster where I'll be hanging out.
While debugging #42085, Patrick from Whonix took a log from the Tor Browser JS console after the fixes from @pierov's testbuild were applied. There are still a few errors showing up in the log. Neither Patrick nor I am confident about whether they're harmless, so probably someone should investigate them.
The most concerning (to my untrained eye) log entries are:
NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIAppStartup.secondsSinceLastOSRestart]
_collectStartupConditionsTelemetry resource:///modules/BrowserGlue.sys.mjs:1649
BG__onFirstWindowLoaded resource:///modules/BrowserGlue.sys.mjs:1759
BG_observe resource:///modules/BrowserGlue.sys.mjs:981
_delayedStartup chrome://browser/content/browser.js:2106
BrowserGlue.sys.mjs:1658:15
uncaught exception: SessionFileInternal.getWriter() called too early! Please read the session file from disk first. 2
TypeError: this.client is undefined
RemoteSecuritySettings.sys.mjs:538:7
See the above forum link for full context on where the errors show up in the log. I have no idea whether these errors also show up in non-Whonix environments. To be clear, Patrick isn't observing any actually-wrong behavior, so probably everything is OK... but seems better to check than assume.
@pierov Patrick confirms that all issues he observed are fixed in your testbuild. So, assuming that the patches in your testbuild get merged, all should be good. \o/
@pierov Patrick has posted some logs in the forum thread I linked previously. My interpretation of the logs is that your testbuild has fixed the issue for him, but I'm not super good at reading logs, so would like to wait for confirmation from him that everything is resolved in the testbuild.
Checking with Patrick to see if he can test with Wireshark.
Hi @pierov , @richard asked me to flag #42085 (closed) for you in relation to this MR.
As requested, I reached out to the Whonix Team about testing the refactored control port + Tor daemon handling code. They tested the latest Tor Browser Alpha (not sure which version, it's whatever was the latest Alpha on 2023 September 8) on Whonix; the test results are as follows. They don't see any obviously-wrong behavior, but they did observe something odd that they wanted me to flag for you: when clicking the New Identity button, they don't observe a NEWNYM signal being sent to the Tor control port. However, the https://check.torproject.org/ page indicates that the exit relay IP does still change.
They suspect that the likely explanation is that the refactored Tor Browser code intentionally no longer uses NEWNYM since changing the SOCKS auth strings is sufficient to get a new circuit, and is less likely to interfere with any other applications that are using the same Tor daemon. However, they wanted me to check with you on whether that's the correct explanation, or if this is some kind of unintentional behavioral change.
Debug logs from Onion-Grater are available at http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/tor-browser-refactored-control-port-tor-daemon-codebase/17164/2 , on the off chance that this helps debug anything.
Forgot to say, I reproed this on Windows 32-bit. No idea if other platforms behave the same.
So I can repro this in both stable and the RC that Pier gave me.
The file I tried to download was a zip. I don't know if PDF files will behave differently. Since Firefox has a bunch of special-case code for PDF handling, there may be subtle differences.
@richard Are we in a position to merge this, or are there still some loose ends from the Mullvad Browser release that we need to wait for?
JeremyRand (bf35009f) at 07 Apr 14:59
Bug 32355: gcc: Add osname to output filename
... and 26 more commits
JeremyRand (e4242ebf) at 03 Apr 14:57
Bug 32355: gcc: Add osname to output filename
... and 5 more commits
Agreed, waiting until next week seems prudent.
JeremyRand (34079e8e) at 29 Mar 10:03
Bug 32355: gcc: Add osname to output filename
... and 5 more commits
Squashed and rebased.
JeremyRand (82c32106) at 28 Mar 05:04
Bug 32355: gcc: Add osname to output filename
... and 16 more commits
I've noticed that the updater drops the
--name
and--class
attributes we pass tofirefox.real
instart-tor-browser
.
Nice detective work @pierov! I can confirm that removing those two attributes from this line triggers the same wrong behavior without needing to invoke the updater: http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/tor-browser-build/-/blob/3f0b4c83bf925b3873d9b5f5b5ca144f242615cd/projects/browser/RelativeLink/start-browser#L364
I've tried on Fedora KDE, which hasn't labels.
Indeed, seems Fedora KDE defaults to not showing text labels for window groups. Try right-clicking on the taskbar, click "Show Alternatives", then switch from "Icons-only Task Manager" to "Task Manager", and click "Switch". That should allow you to reproduce the behavior described in this issue.
Thanks for the review @boklm . I think I've addressed all of your comments. Feel free to review again; if it passes review, let me know and I can squash the fixes into the main commits before it's merged.
Good point. I'm no longer convinced that this TODO is actually a good idea anyway, so I've rewritten the comment so that my current thinking is hopefully a bit more clear.