Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-06-15T02:45:00Zhttps://gitlab.torproject.org/legacy/trac/-/issues/5926language info leaked by JS Date methods in Windows and Linux2022-06-15T02:45:00ZMike Perrylanguage info leaked by JS Date methods in Windows and LinuxIn greg's test at http://pseudo-flaw.net/tor/torbutton/browserfeedwriter-error.html, the Date string ends up localized to the user's language.
We should scrub it or remove it most likely. See also #5922 for info on the relevant source c...In greg's test at http://pseudo-flaw.net/tor/torbutton/browserfeedwriter-error.html, the Date string ends up localized to the user's language.
We should scrub it or remove it most likely. See also #5922 for info on the relevant source code paths.https://gitlab.torproject.org/legacy/trac/-/issues/33745Merge a turbotunnel branch2022-06-01T19:48:57ZDavid Fifielddcf@torproject.orgMerge a turbotunnel branchSnowflake turbo tunnel features have now been through a test deployment (#33336) and a few iterations of Tor Browser packages. There haven't been as many test reports as I'd like, but what testing there has been has been mostly positive....Snowflake turbo tunnel features have now been through a test deployment (#33336) and a few iterations of Tor Browser packages. There haven't been as many test reports as I'd like, but what testing there has been has been mostly positive. Turbo tunnel–like features are a dependency of some of the tasks for a stable release of Snowflake (#19001). So we should merge it.
Some sub-tasks:
* Decide between the [KCP](https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-kcp) and [QUIC branch](https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-quic).
* Test without `LearnCircuitBuildTimeout 0` and find another workaround, if necessary. See comment:15:ticket:33336.
* Rebase and clean history of the chosen branch.
* Redeploy bridge from master.
Summary of turbo tunnel development history till now:
* [Turbo Tunnel in Snowflake](https://lists.torproject.org/pipermail/anti-censorship-team/2020-February/000059.html)
* [Second draft of Turbo Tunnel Snowflake packages](https://lists.torproject.org/pipermail/anti-censorship-team/2020-February/000074.html)
* [Third draft of Turbo Tunnel Snowflake packages](https://lists.torproject.org/pipermail/anti-censorship-team/2020-March/000075.html)
* [[ticket:33336|Trial deployment of Snowflake with Turbo Tunnel]]
* [[ticket:33519|Support multiple simultaneous SOCKS connections]]
One bug that may or not be snowflake's fault:
* [[#33669|"Pluggable Transport process terminated" but Tor keeps on going (and of course doesn't work)]]David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33519Support multiple simultaneous SOCKS connections2022-06-01T19:46:43ZDavid Fifielddcf@torproject.orgSupport multiple simultaneous SOCKS connectionsThe Snowflake client accepts multiple simultaneous SOCKS connections from tor, but it only tries to collect one proxy at a time, and each proxy can service only one SOCKS connection (this is true in the turbotunnel branch as well). One o...The Snowflake client accepts multiple simultaneous SOCKS connections from tor, but it only tries to collect one proxy at a time, and each proxy can service only one SOCKS connection (this is true in the turbotunnel branch as well). One of the SOCKS connections gets the only available proxy, while the others starve.
I can think of a few ways to approach this.
1. Dynamically adjust the `max` parameter according to how many SOCKS connections there are currently. If there's one SOCKS connection, we need only one proxy. If there's another SOCKS connection, raise the limit to allow the proxy-collecting thread to pick up another one, and lower the limit again if the number of SOCKS connections drops back down.
2. Start up a separate proxy-collecting thread for each SOCKS connection, as suggested at comment:12:ticket:21314. Each SOCKS connection will make its own broker requests and collect its own proxies, not interacting with those of any other SOCKS connection. A downside of this is that the number of Snowflake proxies you are contacting leaks the number of SOCKS connections you have ongoing. (Which can also be seen as a benefit in that if there are zero SOCKS connections, you don't even bother to contact the broker.)
3. Make it possible for multiple SOCKS connections to share the same proxy. Continue using a global proxy-collecting thread, and make there be a single shared `RedialPacketConn` instead of a separate one for each SOCKS connection. As things work now, this would require tagging _every packet_ with the ClientID, instead of [sending the ClientID once](https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/snowflake.go?h=turbotunnel&id=47312dd1eccc8456652853bd66f8ed396e9ba6ec#n52) and letting it be the same implicitly for all packets that follow.
4. Make it possible for multiple SOCKS connections to share the same proxy, and use a single KCP/QUIC connection for all SOCKS connections. Separate SOCKS connections go into separate streams within the KCP/QUIC connection. In other words, rather than doing both `sess = kcp.NewConn2/quic.Dial` and `sess.OpenStream` in the SOCKS handler, we do `sess = kcp.NewConn2/quic.Dial` in `main` and then `sess.OpenStream` in the SOCKS handler. This way we could continue tagging the ClientID just once, because the program would only ever work with one ClientID at a time. However this way would make it harder to do the "stop using the network when not being used" of #21314, because that single KCP/QUIC connection would try to keep itself alive all the time and would contact the broker every time it needed a new proxy. Perhaps we could make it so that if there are zero streams, we close the KCP/QUIC connection, and lazily create a new one if and when we get another SOCKS connection.
| |= status quo=|= 1=|= 2=|= 3=|= 4=|
|---------------------------|--------------|--------------|--------------|--------------|--------------|
|= proxy-collecting threads=| one global| one global| one per SOCKS| one global| one global|
|= proxy limit per thread=| 1| # of SOCKS| 1| 1| 1|
|= proxies shared between SOCKSes?=| dedicated| dedicated| dedicated| shared| shared|
|= `PacketConn`s=| one per SOCKS| one per SOCKS| one per SOCKS| one global| one global|
|= KCP/QUIC connections=| one per SOCKS| one per SOCKS| one per SOCKS| one per SOCKS| one global|
|= KCP/QUIC streams=| one per SOCKS| one per SOCKS| one per SOCKS| one per SOCKS| one per SOCKS|
|= ClientID on every packet?=| no| no| no| yes| no|https://gitlab.torproject.org/legacy/trac/-/issues/33283Add caching for the exec function in rbm2022-06-01T19:03:36ZboklmAdd caching for the exec function in rbmIn a mail to tbb-dev, dcf mentioned that while building tor-browser, a lot of time is spent in rbm:
https://lists.torproject.org/pipermail/tbb-dev/2020-February/001045.html
I think an easy way to improve this is by caching the result fr...In a mail to tbb-dev, dcf mentioned that while building tor-browser, a lot of time is spent in rbm:
https://lists.torproject.org/pipermail/tbb-dev/2020-February/001045.html
I think an easy way to improve this is by caching the result from the `exec()` template function. We use it for example with the line `version: '[% c("abbrev") %]'` which runs something like `exec("git log -1 --format=%h")`, which then runs a `git checkout` before running the `git log` command. The `version` value is used in filenames, and build_id, which are then used in a lot of places, but with no caching we end up doing a lot of calls the same `git checkout` and `git log` commands. The switch to `pion` which added a lot of go projects each with their git repository probably made this issue more visible.boklmboklmhttps://gitlab.torproject.org/legacy/trac/-/issues/9173Relocate RelativeLink functionality to Firefox patch2022-05-27T16:01:31ZMike PerryRelocate RelativeLink functionality to Firefox patchWe need to hardcode our home and profile settings from RelativeLink into a Firefox patch so that users still get expected behavior on Mac and Windows if they dock Firefox instead of the RelativeLink exe/containing app.
This will also pr...We need to hardcode our home and profile settings from RelativeLink into a Firefox patch so that users still get expected behavior on Mac and Windows if they dock Firefox instead of the RelativeLink exe/containing app.
This will also prevent situations where TBB ends up set as the default browser or link handler, and gets launched to handle a url without RelativeLink.
This is a pretty bad usability bug, because Firefox will end up using the wrong profile if you launch it without RelativeLink right now.
In most cases, this will cause it to fail closed (because the socks proxy won't be listening), but not if the user already has proxy settings overrides for their default profile.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/30504Investigate if New Identity works properly after moving to ESR 682022-05-26T01:53:55ZAlex CatarineuInvestigate if New Identity works properly after moving to ESR 68Apparently, it seems to be working. But after reloading Browser Console shows a few errors and warnings:
`PushService: onPermissionChange: Error updating registrations: InvalidStateError PushService.jsm:302`
`An IndexedDB transaction t...Apparently, it seems to be working. But after reloading Browser Console shows a few errors and warnings:
`PushService: onPermissionChange: Error updating registrations: InvalidStateError PushService.jsm:302`
`An IndexedDB transaction that was not yet complete has been aborted due to page navigation. IndexedDBHelper.jsm:145:23`
`Error: _initWorker called too early! Please read the session file from disk first. SessionFile.jsm:334:15`
`TypeError: win.gBrowser is undefined ProcessHangMonitor.jsm:410:18`https://gitlab.torproject.org/legacy/trac/-/issues/27511Add New identity button to toolbar2022-05-26T01:52:40ZTracAdd New identity button to toolbarPlease, make possible to put a "new identity button" in the toolbar.
**Trac**:
**Username**: isnaiterPlease, make possible to put a "new identity button" in the toolbar.
**Trac**:
**Username**: isnaiterhttps://gitlab.torproject.org/legacy/trac/-/issues/26353First request after copying and pasting an URL in URL bar seems to go over th...2022-05-26T01:39:58ZGeorg KoppenFirst request after copying and pasting an URL in URL bar seems to go over the catch-all circuitIf one goes e.g. to our blog and copies and pastes a link from the Upcoming Events section (like https://blog.torproject.org/events/first-amendment-21st-century-pittsburgh) and hits return then the first request seems to go over the catc...If one goes e.g. to our blog and copies and pastes a link from the Upcoming Events section (like https://blog.torproject.org/events/first-amendment-21st-century-pittsburgh) and hits return then the first request seems to go over the catch-all circuit:
```
[06-12 08:47:21] Torbutton INFO: tor SOCKS: https://blog.torproject.org/events/first-amendment-21st-century-pittsburgh via
--unknown--:d106e3543536c1d88e4b356a8d2644e8
[06-12 08:47:21] Torbutton INFO: tor SOCKS: https://blog.torproject.org/events/first-amendment-21st-century-pittsburgh via
torproject.org:7ec24bef3562e08e7b096e5b1049cb49
```
If that's indeed the case we need to fix thathttps://gitlab.torproject.org/legacy/trac/-/issues/30290Circuit Display is lost when moving tab to a new window2022-05-26T01:37:35ZAlex CatarineuCircuit Display is lost when moving tab to a new window1. Go to https://www.torproject.org
2. Open circuit display
3. Open New Window
4. Move torproject tab to New Window
5. Circuit display is empty1. Go to https://www.torproject.org
2. Open circuit display
3. Open New Window
4. Move torproject tab to New Window
5. Circuit display is emptyhttps://gitlab.torproject.org/legacy/trac/-/issues/26128Make security slider work with NoScript for ESR602022-05-26T01:12:56ZArthur EdelsteinMake security slider work with NoScript for ESR60NoScript is now rewritten based on WebExtensions and as such no longer uses prefs. So we need to find another way to control it. Here are the prefs we used:
{{{
"noscript.forbidMedia" : [, true, true, true, fals...NoScript is now rewritten based on WebExtensions and as such no longer uses prefs. So we need to find another way to control it. Here are the prefs we used:
{{{
"noscript.forbidMedia" : [, true, true, true, false],
"noscript.global" : [, false, false, false, true ],
"noscript.globalHttpsWhitelist" : [, false, true, true, false],
"noscript.forbidFonts" : [, true, false, false, false],
}}}https://gitlab.torproject.org/legacy/trac/-/issues/24421"Temporarily allow all this page" get inherited when New Identity is chosen.2022-05-18T23:54:20Zcypherpunks"Temporarily allow all this page" get inherited when New Identity is chosen.How to reproduce:
1. Open Tor Browser.
2. Select "High" Security Setting.
3. Go to https://github.com/
4. Click on NoScript icon and choose "Temporarilly allow all this page".
5. You can note that when the page gets refreshed the canvas...How to reproduce:
1. Open Tor Browser.
2. Select "High" Security Setting.
3. Go to https://github.com/
4. Click on NoScript icon and choose "Temporarilly allow all this page".
5. You can note that when the page gets refreshed the canvas prompt is displayed.
6. Select New Identity in the Torbutton.
7. Go to https://github.com/
8. You can notice that the canvas prompt is displayed (meaning JS is enabled, which in turn implies that "Temporarilly allow all this page" gets inherited when New Identity is chosen.)https://gitlab.torproject.org/legacy/trac/-/issues/19200HTML5 video not blocked with placeholder, plays automatically2022-05-18T23:36:09ZTracHTML5 video not blocked with placeholder, plays automaticallyIn Tor Browser 6.0a5, with security level set at Medium-Low or higher, HTML5 video that uses media source extensions (MSE) is able to load and play automatically, without being blocked by a click-to-play NoScript placeholder. The policy ...In Tor Browser 6.0a5, with security level set at Medium-Low or higher, HTML5 video that uses media source extensions (MSE) is able to load and play automatically, without being blocked by a click-to-play NoScript placeholder. The policy for the Medium-Low, Medium-High, and High security levels states that "HTML5 video and audio media become click-to-play via NoScript," but this bug breaks that security policy by allowing HTML5 MSE media to play unobstructed. The browser's attack surface may be increased due to exposure to this media.
I've tested on both OS X and Tails 2.4~rc1. The bug exists on both platforms. On OS X, I tested with a clean install of Tor Browser.
Regular HTML5 video that does not use MSE is unaffected by this bug and gets placeholder-blocked properly.
## Expected result:
HTML5 MSE video should not be allowed to play automatically in security level Medium-Low or higher, it should be replaced with a click-to-play placeholder by NoScript to block it until the user either clicks the placeholder or uses the NoScript toolbar button to allow it. This was the behavior in Tor Browser 5.5.5 and earlier.
## Steps to reproduce:
1. Click the Torbutton icon in the browser toolbar, select "Privacy and Security Settings..." and choose Medium-Low, Medium-High, or High security level.
2. Go to a site that has MSE video, such as any YouTube video, eg: https://www.youtube.com/watch?v=T07gkTc5Fcc
3. If Tor Browser is in High security mode, then allow scripts on the page via the NoScript toolbar button option "Temporarily allow all this page."
4. The video will start playing automatically. There is no NoScript placeholder that you click to start the video, it just starts playing.
**Trac**:
**Username**: potatohttps://gitlab.torproject.org/legacy/trac/-/issues/11406UI for ExitNode country selection in tor-launcher2022-05-18T23:27:33ZMatt PaganUI for ExitNode country selection in tor-launcherUsers often want to know how to make it appear they are coming from a certain country. There should be a more usable way of doing this than manually adding an ExitNodes line in the Tor Browser's torrc. The country code interface should h...Users often want to know how to make it appear they are coming from a certain country. There should be a more usable way of doing this than manually adding an ExitNodes line in the Tor Browser's torrc. The country code interface should have a clear warning that setting a country will make you less anonymous.Kathleen BradeKathleen Bradehttps://gitlab.torproject.org/legacy/trac/-/issues/7255Prompt if Tor Browser is Maximized2022-05-18T23:26:29ZMike PerryPrompt if Tor Browser is MaximizedWe should display some kind of toolbar message or otherwise warn the user against maximizing their Tor Browser window, because maximization reveals monitor resolution and toolbar sizes.We should display some kind of toolbar message or otherwise warn the user against maximizing their Tor Browser window, because maximization reveals monitor resolution and toolbar sizes.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/5715"New Identity" has cache race conditions that temporarily allow evercookies2022-05-18T23:00:06ZTrac"New Identity" has cache race conditions that temporarily allow evercookiesThe TorBrowser is not defending against evercookies.
By pressing the TorBrowserButton "New Identity", the evercookies set by samy.pl/evercookie seem to be cleared, but they are restorable.
This affects the following types of evercookie...The TorBrowser is not defending against evercookies.
By pressing the TorBrowserButton "New Identity", the evercookies set by samy.pl/evercookie seem to be cleared, but they are restorable.
This affects the following types of evercookies:
cacheData mechanism
etag mechanism
pngData mechanism
windowData mechanism
cookieData mechanism
That is a critical behavior because of linkability between different TorBrowser sessions.
If the TorBrowser is completely closed and then reopened, the evercookies seem to be really deleted according to Samy's testing page.
Please check this. Thanks!
**Trac**:
**Username**: guiseppeMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/12994deb.torproject.org archive signing key expired2022-04-26T17:37:18ZTracdeb.torproject.org archive signing key expiredHello, while trying to update Tor on Debian Wheezy I noticed that the gpg key used to sign the apt archive is now expired.
pub 2048R/886DDD89 2009-09-04 [expires: 2014-09-03]
Key fingerprint = A3C4 F0F9 79CA A22C DBA8 F512 ...Hello, while trying to update Tor on Debian Wheezy I noticed that the gpg key used to sign the apt archive is now expired.
pub 2048R/886DDD89 2009-09-04 [expires: 2014-09-03]
Key fingerprint = A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89
uid deb.torproject.org archive signing key
sub 2048R/219EC810 2009-09-04 [expires: 2014-08-29]
Thank you.
**Trac**:
**Username**: TorAmateurDevhttps://gitlab.torproject.org/legacy/trac/-/issues/30735Work out which relays are ignored by all sbws instances2022-04-26T07:58:38ZteorWork out which relays are ignored by all sbws instancesWe need to find out if sbws is excluding any relays.
If the number of excluded relays is small, we can go below 3 torflow instances.We need to find out if sbws is excluding any relays.
If the number of excluded relays is small, we can go below 3 torflow instances.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/29954Parent ticket for scanner improvements2022-04-26T07:58:37ZjugaParent ticket for scanner improvementssbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24197Building Windows 64 firefox with the sandbox enabled fails2022-04-05T16:56:42ZboklmBuilding Windows 64 firefox with the sandbox enabled failsWhen trying to build Tor Browser for Windows 64 with the firefox sandbox enabled, firefox fails to build with the following error:
```
/var/tmp/dist/mingw-w64/helpers/x86_64-w64-mingw32-g++ -std=gnu++11 -mwindows -o file_path.o -c -DND...When trying to build Tor Browser for Windows 64 with the firefox sandbox enabled, firefox fails to build with the following error:
```
/var/tmp/dist/mingw-w64/helpers/x86_64-w64-mingw32-g++ -std=gnu++11 -mwindows -o file_path.o -c -DNDEBUG=1 -DTRIMMED=1 -DUNICODE -D_UNICODE -DNS_NO_XPCOM -D_CRT_RAND_S -DCHROMIUM_SANDBOX_BUILD -I/var/tmp/build/firefox-a99a3504e931/security/sandbox -I/var/tmp/build/firefox-a99a3504e931/obj-mingw/security/sandbox -I/var/tmp/build/firefox-a99a3504e931/security/sandbox/chromium-shim -I/var/tmp/build/firefox-a99a3504e931/security/sandbox/chromium -I/var/tmp/build/firefox-a99a3504e931/nsprpub -I/var/tmp/build/firefox-a99a3504e931/obj-mingw/dist/include -I/var/tmp/build/firefox-a99a3504e931/obj-mingw/dist/include/nspr -I/var/tmp/build/firefox-a99a3504e931/obj-mingw/dist/include/nss -DMOZILLA_CLIENT -include /var/tmp/build/firefox-a99a3504e931/obj-mingw/mozilla-config.h -MD -MP -MF .deps/file_path.o.pp -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-format -fno-lifetime-dse -fno-exceptions -fno-strict-aliasing -mms-bitfields -fno-rtti -fno-exceptions -fno-math-errno -pipe -g -O -fomit-frame-pointer /var/tmp/build/firefox-a99a3504e931/security/sandbox/chromium-shim/base/files/file_path.cpp
In file included from /var/tmp/build/firefox-a99a3504e931/security/sandbox/chromium/base/files/file_path.h:113:0,
from /var/tmp/build/firefox-a99a3504e931/security/sandbox/chromium-shim/base/files/file_path.cpp:9:
/var/tmp/build/firefox-a99a3504e931/security/sandbox/chromium/base/containers/hash_tables.h: In member function 'std::size_t base_hash::hash<T*>::operator()(T*) const':
/var/tmp/build/firefox-a99a3504e931/security/sandbox/chromium/base/containers/hash_tables.h:79:43: error: no match for call to '(__gnu_cxx::hash<long long unsigned int>)
(uintptr_t)'
reinterpret_cast<uintptr_t>(value));
^
/var/tmp/build/firefox-a99a3504e931/nsprpub/pr/src/io/prpolevt.c: In function 'PR_NewPollableEvent':
/var/tmp/build/firefox-a99a3504e931/nsprpub/pr/src/io/prpolevt.c:121:14: warning: variable 'rv' set but not used [-Wunused-but-set-variable]
PRStatus rv;
^
make[5]: *** [file_path.o] Error 1
make[5]: Leaving directory `/var/tmp/build/firefox-a99a3504e931/obj-mingw/security/sandbox'
make[4]: *** [security/sandbox/target] Error 2
```https://gitlab.torproject.org/legacy/trac/-/issues/2681brainstorm ways to let Tor clients use yesterday's consensus more safely2022-03-22T13:28:40ZRoger Dingledinebrainstorm ways to let Tor clients use yesterday's consensus more safelyRight now Tor clients won't use a consensus that's 25 hours old. But if the directory authorities don't agree on a consensus for a day, things can go bad. We need to investigate other tradeoffs in this space than the one we've currently ...Right now Tor clients won't use a consensus that's 25 hours old. But if the directory authorities don't agree on a consensus for a day, things can go bad. We need to investigate other tradeoffs in this space than the one we've currently picked.
For instance: if you got your directory consensus info when it was valid, but you haven't been able to get any new consensus, perhaps you should be more forgiving about the timestamp on the consensus you have. That's a slightly different scenario than believing a new consensus that's 48 hours old.
Another option is just to change 24 to 48, which probably doesn't put clients at much greater harm, but gives us a lot more breathing room for mistakes.
The implementation side of this will be tricky, because we'll need to make sure that clients can handle descriptors that are 36 hours out of date too. We started implementing that feature several times, but I think we've never finished it.Tor: unspecified