The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:31:36Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34242Creating containers for Linux targets is busted due to outdated apt2020-06-27T14:31:36ZGeorg KoppenCreating containers for Linux targets is busted due to outdated aptFor Linux containers we hardcode `0.9.7.9+deb7u8` as the minimal `apt` version but that's not available anymore on `deb.freexian.com`. Rather it's `0.9.7.9+deb7u9` now.For Linux containers we hardcode `0.9.7.9+deb7u8` as the minimal `apt` version but that's not available anymore on `deb.freexian.com`. Rather it's `0.9.7.9+deb7u9` now.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34243debootstrap-image project for Linux fails with segfault2020-06-27T14:31:36ZGeorg Koppendebootstrap-image project for Linux fails with segfaultOn one of my machines creating a Linux container fails:
```
W: Failure trying to run: chroot "/var/tmp/tmp.HiqNC7Q599/base-image" dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb
W: See /var/tmp/tmp.Hiq...On one of my machines creating a Linux container fails:
```
W: Failure trying to run: chroot "/var/tmp/tmp.HiqNC7Q599/base-image" dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb
W: See /var/tmp/tmp.HiqNC7Q599/base-image/debootstrap/debootstrap.log for details
```
And that log says:
```
2020-05-17 19:15:26 URL:http://archive.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.7.dfsg-13_amd64.deb [87392/87392] -> "/var/tmp/tmp.uv7kNeRkLc/base-image//var/cache/apt/archives/partial/zlib1g_1%3a1.2.7.dfsg-13_amd64.deb" [1]
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
missing architecture
Segmentation fault
```
I originally hit this when trying to solve legacy/trac#34242. To have a chance to repro one needs the fix for legacy/trac#34242, too.https://gitlab.torproject.org/tpo/core/tor/-/issues/20930Use new systemd hardening options2020-07-27T19:39:21ZTracUse new systemd hardening optionsUsing systemd 232, I discovered some more hardening options. This is my working systemd unit file.
I'd say the most interesting one is "PrivateUsers" and "PrivateDevices"
Note that I start tor directly as the tor user, listening on ports...Using systemd 232, I discovered some more hardening options. This is my working systemd unit file.
I'd say the most interesting one is "PrivateUsers" and "PrivateDevices"
Note that I start tor directly as the tor user, listening on ports > 1024, because CAP_NET_BIND_SERVICE isn't enough to listen on ports < 1024.
Setting this capability is enough to start dnsmasq as non-root (listening on correct ports), so it is something within tor that breaks.
AFAIK setting these is safe even for older systems since systemd ignores unknown keywords.
```
[Unit]
Description=The Onion Router
After=network-online.target
[Service]
User=tor
Group=tor
ExecStartPre=/usr/bin/tor --verify-config -f /etc/tor/torrc
ExecStart=/usr/bin/tor --RunAsDaemon 0 -f /etc/tor/torrc
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGINT
TimeoutStopSec=32
LimitNOFILE=32768
# Hardening options:
#CapabilityBoundingSet = CAP_NET_BIND_SERVICE
#AmbientCapabilities = CAP_NET_BIND_SERVICE
# Capabilities aren't enough to have ports < 1024
RuntimeDirectory=tor
RuntimeDirectoryMode=0700 # Tor is happy with this default mask
ReadWriteDirectories=/var/lib/tor/
PrivateTmp = yes
PrivateUsers = yes
ProtectKernelTunables = yes
ProtectControlGroups = yes
ProtectKernelModules = yes
PrivateDevices = yes
ProtectHome = yes
ProtectSystem = strict
NoNewPrivileges = yes
[Install]
WantedBy=multi-user.target
```
**Trac**:
**Username**: serafeanTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20931[prop271] Generate GUARD controller events2021-09-16T14:33:05ZNick Mathewson[prop271] Generate GUARD controller eventsTor: unspecifiedhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34247Update tor-browser-build README2020-06-27T14:31:35ZGeorg KoppenUpdate tor-browser-build READMEOver the time some errors and things to correct have accumulated in the `README` file. We should fix them.Over the time some errors and things to correct have accumulated in the `README` file. We should fix them.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20932Coding Standards: No changes file for bug fix on unreleased code2021-07-22T16:22:54ZTracCoding Standards: No changes file for bug fix on unreleased codeWhile reviewing legacy/trac#20572, dgoulet said that a changes file is not used when fixing something that has not been released.
That's not stated in the `CodingStandards.md` yet, so it would help new contributors to clarify this.
**T...While reviewing legacy/trac#20572, dgoulet said that a changes file is not used when fixing something that has not been released.
That's not stated in the `CodingStandards.md` yet, so it would help new contributors to clarify this.
**Trac**:
**Username**: jryansTor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20933Update to December GeoIP2 database2020-06-27T13:57:37ZKarsten LoesingUpdate to December GeoIP2 database[geoip-dec2016](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-dec2016) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.[geoip-dec2016](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-dec2016) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34250Fix torbutton noscript-control race condition2020-06-27T14:31:35ZAlex CatarineuFix torbutton noscript-control race conditionWhile debugging some testsuite tests, I saw some race condition with the noscript initialization which prevents some tests from running correctly.
We currently listen for both `startup` and `pageshow` events [here](https://gitweb.torpro...While debugging some testsuite tests, I saw some race condition with the noscript initialization which prevents some tests from running correctly.
We currently listen for both `startup` and `pageshow` events [here](https://gitweb.torproject.org/torbutton.git/tree/modules/noscript-control.js?id=36f8182a25818548d62b7fbc6be4d2472773b820#n149), and in some tests, `pageshow` events are being received before `startup`, which results in the configuration message being lost and noscript being initialized with the default settings, blocking scripts.
This was originally introduced in legacy/trac#27427, which added checks for the event types precisely because of these issues. However, "pageshow" in specific situations also seems to trigger those.
In that ticket, "pageshow" was added `for a slightly more graceful failure mode in case Torbutton somehow misses NoScript startup`. However, I don't think that can really happen, and I suggest we just listen to `startup`.https://gitlab.torproject.org/tpo/core/tor/-/issues/20935Typo in macOS Sierra macro in configure2020-06-27T13:57:37ZteorTypo in macOS Sierra macro in configuresbs reports that there is a typo in the MAC_OS_VERSION_10_12 macro in:
https://gitweb.torproject.org/tor.git/tree/configure.ac#n433
(It's missing an 'X_'.)
This has no impact, because we define MAC_OS_VERSION_10_12 if it's not defined (...sbs reports that there is a typo in the MAC_OS_VERSION_10_12 macro in:
https://gitweb.torproject.org/tor.git/tree/configure.ac#n433
(It's missing an 'X_'.)
This has no impact, because we define MAC_OS_VERSION_10_12 if it's not defined (which it never is).
This was introduced in commit 16fcbd21 in tor-0.2.8.10.
Reported by Simone Basso, please credit in changes file.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34252Fix Android x86_64 testbuild2020-06-27T14:31:35ZMatthew FinkelFix Android x86_64 testbuildIn legacy/trac#32788, we began using a constant build date in the testbuild. Unfortunately, on Android x86_64 (and I assume aarch64), we hit:
```
0:02.07 Traceback (most recent call last):
0:02.07 File "/usr/lib/python2.7/runpy.py",...In legacy/trac#32788, we began using a constant build date in the testbuild. Unfortunately, on Android x86_64 (and I assume aarch64), we hit:
```
0:02.07 Traceback (most recent call last):
0:02.07 File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
0:02.07 "__main__", fname, loader, pkg_name)
0:02.07 File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
0:02.07 exec code in run_globals
0:02.07 File "/var/tmp/build/firefox-4acec7610371/python/mozbuild/mozbuild/action/file_generate.py", line 120, in <module>
0:02.07 sys.exit(main(sys.argv[1:]))
0:02.07 File "/var/tmp/build/firefox-4acec7610371/python/mozbuild/mozbuild/action/file_generate.py", line 71, in main
0:02.07 ret = module.__dict__[method](output, *args.additional_arguments, **kwargs)
0:02.07 File "/var/tmp/build/firefox-4acec7610371/mobile/android/base/generate_build_config.py", line 145, in generate_android_manifest
0:02.07 defines=_defines(),
0:02.07 File "/var/tmp/build/firefox-4acec7610371/mobile/android/base/generate_build_config.py", line 129, in _defines
0:02.07 max_sdk=max_sdk)
0:02.07 File "/var/tmp/build/firefox-4acec7610371/python/mozbuild/mozbuild/android_version_code.py", line 140, in android_version_code
0:02.07 return android_version_code_v0(buildid, *args, **kwargs)
0:02.07 File "/var/tmp/build/firefox-4acec7610371/python/mozbuild/mozbuild/android_version_code.py", line 31, in android_version_code_v0
0:02.07 "for CPU arch %s" % cpu_arch)
0:02.07 ValueError: Don't know how to compute android:versionCode for CPU arch x86_64
0:02.07 make[4]: *** [backend.mk:11: .deps/AndroidManifest.xml.stub] Error 1
0:02.07 make[4]: Leaving directory '/var/tmp/build/firefox-4acec7610371/obj-x86_64-linux-android/mobile/android/base'
0:02.07 make[3]: *** [/var/tmp/build/firefox-4acec7610371/config/recurse.mk:101: mobile/android/base/export] Error 2
0:02.07 make[3]: *** Waiting for unfinished jobs...
```
` 0:02.07 ValueError: Don't know how to compute android:versionCode for CPU arch x86_64`
This is because the fixed build date (`20010101010101`) is less than `20150801000000`, and this results in the Firefox build system using the old Android version code scheme which only supports x86 and armv7.https://gitlab.torproject.org/tpo/core/tor/-/issues/20936Test: fix memory leak in test_circuituse.c2020-06-27T13:57:37ZDavid Gouletdgoulet@torproject.orgTest: fix memory leak in test_circuituse.cCaught by our expensive hardening.Caught by our expensive hardening.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20937Debian 0.2.8.11 package CapabilityBoundingSet doesn't allow tor to start with...2020-06-27T13:57:37ZDavid Gouletdgoulet@torproject.orgDebian 0.2.8.11 package CapabilityBoundingSet doesn't allow tor to start with a configured HSLatest 0.2.8.11 package changes the capabilities from the systemd service file from:
```
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE CAP_CHOWN CAP_FOWNER
```
to
```
CapabilityBoundingSet=CAP_SETUI...Latest 0.2.8.11 package changes the capabilities from the systemd service file from:
```
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE CAP_CHOWN CAP_FOWNER
```
to
```
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
```
which makes it that tor doesn't restart after an upgrade with at least one hidden service configured:
```
[warn] Directory /var/lib/tor/hidden_service/ cannot be read: Permission denied
```
This is pretty bad because anyone upgrading will have its tor stopped. (from deb.tpo)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34305NoScript inconsistent behaviour in Firefox 77 (currently beta)2020-06-27T14:31:35ZAlex CatarineuNoScript inconsistent behaviour in Firefox 77 (currently beta)While working on fixing the testsuite (legacy/trac#27105) I ran into some inconsistent blocking behaviour of NoScript in a Tor Browser WIP build based on Firefox 77 beta.
Basically, the issue is that with Tor Browser `Safer` NoScript c...While working on fixing the testsuite (legacy/trac#27105) I ran into some inconsistent blocking behaviour of NoScript in a Tor Browser WIP build based on Firefox 77 beta.
Basically, the issue is that with Tor Browser `Safer` NoScript configuration when visiting a `http:` page (containing a https: iframe) and then going to the `https:` version of the same page results in JavaScript being blocked, but it should not be. Manually reloading the `https:` page results in JavaScript being executed correctly.
After some effort, I managed to reproduce in current Firefox 77 beta directly, more specifically: `f2e0df68e569b43ca337535927ed63068ed01c664eea7e397378cae668f63d0a firefox-77.0b9.tar.bz2`. Tested with NoScript 11.0.26 and 11.0.25.
Steps to reproduce (in a fresh profile):
- Install NoScript addon.
- Go to NoScript options page (either via about:addons or via NoScript toolbar badge).
- Enable "script" option and "Cascade top document's restrictions to subdocuments" in the General + Default tab.
- Still in General, go to "UNTRUSTED" and enable "frame".
- Go to "Per-site permission" tab and add a new rule: "http:" and mark it as "untrusted" (basically, setting non-https pages as untrusted).
- Open a new tab and visit http://alltaken.xyz/https_iframe.html
- When loaded, open a new tab and visit https://alltaken.xyz/https_iframe.html
- Result: JavaScript is blocked, but it should not be. When the page is manually reloaded (press F5), the script is executed correctly, and the `JavaScriptEnabled` text is displayed.https://gitlab.torproject.org/tpo/core/tor/-/issues/20938Test: memory leak in single onion service test2020-06-27T13:57:37ZDavid Gouletdgoulet@torproject.orgTest: memory leak in single onion service testFound by the expensive hardening:
```
hs/single_onion_poisoning_create_dir_none: [forking]
=================================================================
==29309==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 102 byte(...Found by the expensive hardening:
```
hs/single_onion_poisoning_create_dir_none: [forking]
=================================================================
==29309==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 102 byte(s) in 2 object(s) allocated from:
#0 0x7f93a6775eb0 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc6eb0)
#1 0x7f93a41dcbf9 in __strdup (/lib/x86_64-linux-gnu/libc.so.6+0x8cbf9)
SUMMARY: AddressSanitizer: 102 byte(s) leaked in 2 allocation(s).
OK
hs/single_onion_poisoning_create_dir1: [forking]
=================================================================
==29311==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 102 byte(s) in 2 object(s) allocated from:
#0 0x7f93a6775eb0 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc6eb0)
#1 0x7f93a41dcbf9 in __strdup (/lib/x86_64-linux-gnu/libc.so.6+0x8cbf9)
SUMMARY: AddressSanitizer: 102 byte(s) leaked in 2 allocation(s).
OK
hs/single_onion_poisoning_create_dir2: [forking]
=================================================================
==29313==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 102 byte(s) in 2 object(s) allocated from:
#0 0x7f93a6775eb0 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc6eb0)
#1 0x7f93a41dcbf9 in __strdup (/lib/x86_64-linux-gnu/libc.so.6+0x8cbf9)
SUMMARY: AddressSanitizer: 102 byte(s) leaked in 2 allocation(s).
OK
hs/single_onion_poisoning_create_dir_both: [forking]
=================================================================
==29315==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 102 byte(s) in 2 object(s) allocated from:
#0 0x7f93a6775eb0 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc6eb0)
#1 0x7f93a41dcbf9 in __strdup (/lib/x86_64-linux-gnu/libc.so.6+0x8cbf9)
SUMMARY: AddressSanitizer: 102 byte(s) leaked in 2 allocation(s).
OK
```
Patch coming up.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34315avoid reading policies from /etc/firefox on Linux2020-06-27T14:31:35ZMark Smithavoid reading policies from /etc/firefox on LinuxGeorg noticed that Firefox 77 and ESR 68.9 will include a fix for this bug:
"Read Linux policy from etc/opt directory"
https://bugzilla.mozilla.org/show_bug.cgi?id=1469629
Here is the patch:
https://hg.mozilla.org/releases/mozilla-esr68...Georg noticed that Firefox 77 and ESR 68.9 will include a fix for this bug:
"Read Linux policy from etc/opt directory"
https://bugzilla.mozilla.org/show_bug.cgi?id=1469629
Here is the patch:
https://hg.mozilla.org/releases/mozilla-esr68/rev/203a8c227a997c4ae7e970d0ec497d7292078d5c
Unfortunately, with that patch in place, policies will be read from /etc/firefox/policies/policies.json if it exists. For Tor Browser we do not want that behavior.
In the short run we can back out the Mozilla patch. In the long run should we handle this via a fixup for our legacy/trac#32418 patch.https://gitlab.torproject.org/tpo/core/tor/-/issues/20950Design guard algorithm tweaks to be more tolerant when picking directory guard.2020-06-27T13:57:37ZNick MathewsonDesign guard algorithm tweaks to be more tolerant when picking directory guard.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20953Isolate references to versioning2021-09-16T14:33:05ZChelsea KomloIsolate references to versioningCurrently, we have versioning references in hard-coded strings in a couple places around the codebase. For example, in protover.c and dirserv.c
It would be useful to isolate these references to a single location, so that in the future, ...Currently, we have versioning references in hard-coded strings in a couple places around the codebase. For example, in protover.c and dirserv.c
It would be useful to isolate these references to a single location, so that in the future, when we need to update/change versions, it is obvious all the places that we might need to do it, and what duplication already exists.
This will hopefully help prevent bugs such as legacy/trac#20810 in the future.Tor: unspecifiedChelsea KomloChelsea Komlohttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34321Add What's New Onboarding Item2020-06-27T14:31:35ZMatthew FinkelAdd What's New Onboarding Itemhttps://trac.torproject.org/projects/tor/ticket/31660#comment:20
"""
We should have something included in the 9.5 release onboarding for the new features. Antonela and I decided we can have one new entry named "What's New" (following Mo...https://trac.torproject.org/projects/tor/ticket/31660#comment:20
"""
We should have something included in the 9.5 release onboarding for the new features. Antonela and I decided we can have one new entry named "What's New" (following Mozilla's new onboarding experience). This entry simply has a link to a webpage where new features are described.
The webpage is currently being developed at https://www.torproject.org/releases/tor-browser-95/
"""https://gitlab.torproject.org/tpo/core/tor/-/issues/20956optionally do not write command line config to torrc2020-09-08T16:55:44ZMark Smithoptionally do not write command line config to torrcFor Tor Browser/Tor Launcher, we have a use case where we want to pass ControlPort and SocksPort options on the command line (aka as program args) and be assured they will never be written to torrc, e.g., in response to a SAVECONF contro...For Tor Browser/Tor Launcher, we have a use case where we want to pass ControlPort and SocksPort options on the command line (aka as program args) and be assured they will never be written to torrc, e.g., in response to a SAVECONF control port command.
See ticket:20906#comment:7 for some background. Also, in ticket:20906#comment:8 nickm said:
I think that a "Don't write this to torrc" flag might be workable, but I also think it's maybe less easy to implement than you might think -- especially if it needs to work for things other than LineList options. If it's LineList only, it has a reasonable chance of being easy to implement.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34344Can Firefox's background connections help us detect interference?2022-07-08T21:16:50ZMatthew FinkelCan Firefox's background connections help us detect interference?Firefox connects to pre-defined URL for testing if it is behind a captive portal. Tor Browser disables that (legacy/trac#21790).
Can any of Firefox's background connections be used as a way of probing the local network (or ISP) for netw...Firefox connects to pre-defined URL for testing if it is behind a captive portal. Tor Browser disables that (legacy/trac#21790).
Can any of Firefox's background connections be used as a way of probing the local network (or ISP) for network interference? If we use them, how can we blend in with Firefox?