The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-02-28T19:41:25Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33411Make DirCache default to 0 on Windows relays, if we can't fix the mmap issues2022-02-28T19:41:25ZteorMake DirCache default to 0 on Windows relays, if we can't fix the mmap issuesIn legacy/trac#24857, tor's consensus diff cache implementation causes high CPU load on Windows.
As a workaround, we could make DirCache default to 0 on Windows.In legacy/trac#24857, tor's consensus diff cache implementation causes high CPU load on Windows.
As a workaround, we could make DirCache default to 0 on Windows.Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32729"hs_circuitmap_init: Assertion !the_hs_circuitmap failed" when repeating fail...2023-03-23T09:17:08Zeighthave"hs_circuitmap_init: Assertion !the_hs_circuitmap failed" when repeating failed tests on AndroidWhen repeated running the Android `TorService` test suite from https://gitlab.com/eighthave/tor-android, I occasionally received this crash:
```
main src/feature/hs/hs_circuitmap.c:598: hs_circuitmap_init: Assertion !the_hs_circu...When repeated running the Android `TorService` test suite from https://gitlab.com/eighthave/tor-android, I occasionally received this crash:
```
main src/feature/hs/hs_circuitmap.c:598: hs_circuitmap_init: Assertion !the_hs_circuitmap failed; aborting.
TorService Bug: Tor 0.4.2.5 (git-7e55ab23311d00b6): Assertion !the_hs_circuitmap failed in hs_circuitmap_init at src/feature/hs/hs_circuitmap.c:598: . (Stack trace not available) (on Tor 0.4.2.5 7e55ab23311d00b6)
libc Fatal signal 6 (SIGABRT), code -6 in tid 862 (tor), pid 836 (oid.binary.test)
TorService ⇠ run [1425ms]
DEBUG #00 pc 00000af0 [vdso:f319a000] (__kernel_vsyscall+16)
#01 pc 0001edf8 /system/lib/libc.so (syscall+40)
#02 pc 0001f073 /system/lib/libc.so (abort+115)
#03 pc 0025ab6e /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (tor_raw_abort_+31)
#04 pc 0025673e /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (tor_abort_+31)
#05 pc 0014df1d /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (hs_circuitmap_init+146)
#06 pc 00154110 /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (hs_init+39)
#07 pc 000b17ac /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (tor_init+132)
#08 pc 000b2033 /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (tor_run_main+243)
#09 pc 000b0933 /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/lib/x86/libtor.so (Java_org_torproject_jni_TorService_runMain+59)
#10 pc 000085c8 /data/app/org.torproject.android.binary.test-FWLW5957oXEttHq4Pbyz4w==/oat/x86/base.odex (offset 0x8000)
#11 pc 000091ff [anon:libc_malloc:e6980000]
#12 pc 01114457 /dev/ashmem/dalvik-main space (region space) (deleted)
#13 pc 80e30d65 <unknown>
```
* I think this only happened if Tor quit the test before due to bad command line args
* it could be that the Android Test Orchestrator is reusing state that it shouldn't be https://developer.android.com/training/testing/junit-runner#using-android-test-orchestrator
* "The Dalvik process hosting a typical app is forked off of zygote with all the common android libraries already mapped, so new unique copies don't have to be opened" https://stackoverflow.com/questions/9153166/understanding-android-zygote-and-dalvikvm
nickm said:
> So there are at least two possibilities:
> 1) tor is busted and is calling hs_circuitmap_init() more than it should
> 2) tor is busted and is calling hs_circuitmap_free_all() less than it should there are probably more, like:
> 3) there is a problem in the android harness, and it is trying to restart tor before it has shut downTor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31364tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:494: warn_if_nu...2023-07-16T12:12:44ZTractor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:494: warn_if_nul_found: Non-fatal assertion !(nul_found) failed. (on Tor 0.4.0.5) [also on 0.4.5.8]
```
Aug 07 11:00:15.000 [notice] Tor 0.4.0.5 opening log file.
Aug 07 11:00:15.393 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 101000af: ...
```
Aug 07 11:00:15.000 [notice] Tor 0.4.0.5 opening log file.
Aug 07 11:00:15.393 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 101000af: OpenSSL 1.1.0j 20 Nov 2018; running with 101000bf: OpenSSL 1.1.0k 28 May 2019).
Aug 07 11:00:15.395 [notice] Can't get entropy from getrandom(). You are running a version of Tor built to support getrandom(), but the kernel doesn't implement this function--probably because it is too old? Trying fallback method instead.
Aug 07 11:00:15.398 [notice] Tor 0.4.0.5 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0k, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Aug 07 11:00:15.398 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download
Aug 07 11:00:15.398 [warn] Tor was compiled with zstd 1.1.2, but is running with zstd 1.3.8. For safety, we'll avoid using advanced zstd functionality.
Aug 07 11:00:15.399 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Aug 07 11:00:15.399 [notice] Read configuration file "/etc/tor/torrc".
Aug 07 11:00:15.407 [notice] Based on detected system memory, MaxMemInQueues is set to 384 MB. You can override this by setting MaxMemInQueues by hand.
Aug 07 11:00:15.410 [notice] I think we have 40 CPUS, but only 1 of them are available. Telling Tor to only use 1. You can override this with the NumCPUs option
Aug 07 11:00:15.411 [notice] Opening OR listener on 0.0.0.0:443
Aug 07 11:00:15.411 [notice] Opened OR listener on 0.0.0.0:443
Aug 07 11:00:15.411 [notice] Opening OR listener on [***]:443
Aug 07 11:00:15.412 [notice] Opened OR listener on [***]:443
Aug 07 11:00:15.412 [notice] Opening Directory listener on 0.0.0.0:9030
Aug 07 11:00:15.412 [notice] Opened Directory listener on 0.0.0.0:9030
Aug 07 11:00:15.000 [notice] Not disabling debugger attaching for unprivileged users.
Aug 07 11:00:15.000 [warn] Found empty file "1037" in consensus cache; removing it.
Aug 07 11:00:15.000 [warn] Unable to map file (null) from consensus cache: No such file or directory
Aug 07 11:00:16.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Aug 07 11:00:17.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Aug 07 11:00:17.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Aug 07 11:00:17.000 [notice] Your Tor server's identity key fingerprint is '***'
Aug 07 11:00:17.000 [notice] Bootstrapped 0% (starting): Starting
Aug 07 11:00:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:494: warn_if_nul_found: Non-fatal assertion !(nul_found) failed. (on Tor 0.4.0.5)
Aug 07 11:00:17.000 [warn] Bug: Non-fatal assertion !(nul_found) failed in warn_if_nul_found at ../src/feature/nodelist/microdesc.c:494. Stack trace: (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x47) [0x55e3b15b98e7] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x55e3b15b4db0] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(+0x11e43f) [0x55e3b14d643f] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(microdesc_cache_reload+0xce) [0x55e3b14d89ee] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(get_microdesc_cache+0x48) [0x55e3b14d8ad8] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(nodelist_set_consensus+0x3fd) [0x55e3b14e4e3d] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(networkstatus_set_current_consensus+0x927) [0x55e3b14dd9d7] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(+0x125dfe) [0x55e3b14dddfe] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(router_reload_consensus_networkstatus+0x45) [0x55e3b14ddeb5] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(run_tor_main_loop+0xec) [0x55e3b141564c] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x11e5) [0x55e3b1416b05] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x55e3b1413c8a] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x55e3b1413809] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f10090512e1] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x55e3b141385a] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] warn_if_nul_found(): Bug: Found unexpected NUL while reading microdesc journal, offset 0at position 295945/331210. (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] warn_if_nul_found(): Bug: surrounding string: 595630544A522B5159546D49496A300A00000000000000000000000000000000 (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] parse error: internal NUL character.
Aug 07 11:00:17.000 [warn] Unparseable microdescriptor found in journal
Aug 07 11:00:27.000 [notice] Starting with guard context "default"
Aug 07 11:00:27.000 [notice] Signaled readiness to systemd
Aug 07 11:00:27.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
```
Apart from that error message Tor seems to work fine.
The relay was running on a VM and when i saw that error the whole VM behaved strange. I think the ISP corrupted something so maybe that error isnt Tor's fault.
**Trac**:
**Username**: computer_freakTor: 0.4.7.x-freezehttps://gitlab.torproject.org/tpo/applications/tor-browser-bundle-testsuite/-/issues/40030Fix onion_client_auth2022-02-04T21:42:42ZMatthew FinkelFix onion_client_auth```
mozversion application_buildid: 20210810010101
mozversion application_display_name: Tor Browser ...```
mozversion application_buildid: 20210810010101
mozversion application_display_name: Tor Browser
mozversion application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
mozversion application_name: Firefox
mozversion application_remotingname: firefox
mozversion application_vendor: Mozilla
mozversion application_version: 78.12.0
mozversion platform_buildid: 20210810010101
mozversion platform_version: 78.12.0
Application command: /home/sysrqb/tor-browser-bundle-testsuite/tmp/FjDegO9ORB/tor-browser_en-US/Browser/ff_wrapper -no-remote -marionette -profile /home/sysrqb/tor-browser-bundle-testsuite/reports/r/tbb.
nightly.2021.08.10_onion_client_auth/results-tor-browser-linux64-tbb-nightly.2021.08.10_en-US.tar.xz/onion_client_auth_ws/tmpZWwYGi.profile.default
Profile path is /home/sysrqb/tor-browser-bundle-testsuite/reports/r/tbb.nightly.2021.08.10_onion_client_auth/results-tor-browser-linux64-tbb-nightly.2021.08.10_en-US.tar.xz/onion_client_auth_ws/tmpZWwYGi
.profile.default
Starting fixture servers
Fixture server listening on http://127.0.0.1:33281/
Fixture server listening on https://127.0.0.1:35923/
e10s is enabled
mozversion application_buildid: 20210810010101
mozversion application_display_name: Tor Browser
mozversion application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
mozversion application_name: Firefox
mozversion application_remotingname: firefox
mozversion application_vendor: Mozilla
mozversion application_version: 78.12.0
mozversion platform_buildid: 20210810010101
mozversion platform_version: 78.12.0
SUITE-START | Running 1 tests
TEST-START | ../../../../marionette/tor_browser_tests/test_onion_client_auth.py Test.test_client_auth
Application command: /home/sysrqb/tor-browser-bundle-testsuite/tmp/FjDegO9ORB/tor-browser_en-US/Browser/ff_wrapper -no-remote -marionette -profile /home/sysrqb/tor-browser-bundle-testsuite/reports/r/tbb.
nightly.2021.08.10_onion_client_auth/results-tor-browser-linux64-tbb-nightly.2021.08.10_en-US.tar.xz/onion_client_auth_ws/tmpZWwYGi.profile.default
TEST-UNEXPECTED-ERROR | ../../../../marionette/tor_browser_tests/test_onion_client_auth.py Test.test_client_auth | NoSuchElementException: Unable to locate element: enumeration
stacktrace:
WebDriverError@chrome://marionette/content/error.js:175:5
NoSuchElementError@chrome://marionette/content/error.js:387:5
element.find/</<@chrome://marionette/content/element.js:330:16
Traceback (most recent call last):
File "/home/sysrqb/tor-browser-bundle-testsuite/virtualenv-marionette-5.0.0/local/lib/python2.7/site-packages/marionette_harness-5.0.0-py2.7.egg/marionette_harness/marionette_test/testcases.py", line 1
59, in run
testMethod()
File "/home/sysrqb/tor-browser-bundle-testsuite/marionette/tor_browser_tests/test_onion_client_auth.py", line 183, in test_client_auth
m.find_element('id', 'enumeration')
File "/home/sysrqb/tor-browser-bundle-testsuite/virtualenv-marionette-5.0.0/local/lib/python2.7/site-packages/marionette_driver-3.0.0-py2.7.egg/marionette_driver/marionette.py", line 1694, in find_elem
ent
body, key="value")
File "/home/sysrqb/tor-browser-bundle-testsuite/virtualenv-marionette-5.0.0/local/lib/python2.7/site-packages/marionette_driver-3.0.0-py2.7.egg/marionette_driver/decorators.py", line 26, in _
return func(*args, **kwargs)
File "/home/sysrqb/tor-browser-bundle-testsuite/virtualenv-marionette-5.0.0/local/lib/python2.7/site-packages/marionette_driver-3.0.0-py2.7.egg/marionette_driver/marionette.py", line 598, in _send_mess
age
self._handle_error(err)
File "/home/sysrqb/tor-browser-bundle-testsuite/virtualenv-marionette-5.0.0/local/lib/python2.7/site-packages/marionette_driver-3.0.0-py2.7.egg/marionette_driver/marionette.py", line 618, in _handle_er
ror
raise errors.lookup(error)(message, stacktrace=stacktrace)
TEST-INFO took 61639ms
```Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40256SVG images don't load on error pages2023-11-27T14:10:13ZtorrrrrrrrrrrrrrrrSVG images don't load on error pagesVersion: 10.0a9
I'm talking about `.cls{fill:url(#radial-gradient);}.cls-2` … thing above the actual error message (Proxy Server Refused Connection).
<img src="/uploads/d819b553762562508803a025166037b6/tor_browser_alpha_10.0a9-proxy-se...Version: 10.0a9
I'm talking about `.cls{fill:url(#radial-gradient);}.cls-2` … thing above the actual error message (Proxy Server Refused Connection).
<img src="/uploads/d819b553762562508803a025166037b6/tor_browser_alpha_10.0a9-proxy-server-refused-connection.png" width="300">Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40196java.io.IOException: Control port file not created2024-01-18T17:39:01Zaylinsumerjava.io.IOException: Control port file not createdDear Sir/Madam,
I am using tor browser app on my android phone (You can find model/version of my hardware/software below).
When i tap on tor browser icon on the screen, app tries to connect to the tor network, but couldn't succeed (You...Dear Sir/Madam,
I am using tor browser app on my android phone (You can find model/version of my hardware/software below).
When i tap on tor browser icon on the screen, app tries to connect to the tor network, but couldn't succeed (You can find the screenshot of the application log below).
I've been using tor browser app for years and started to experience the problem 5-6 months ago. Tor browser app has been upgraded 4 or 5 times since then. However, none of them solved the problem.
At the moment, both stable version (68.12.0) and alpha version (10.0a8-81.1.2-Beta) are installed on my phone. Both versions give the same error message.
Lastly, i am living in Turkey and using obfs4 bridge. My phone is not rooted.
thank you for your interest,
sincerely,
Aylin Sumer
--------------------
phone: asus zenfone max (ZC550KL)
os: android 5.0.2
tor browser alpha: 10.0a8 (81.1.2-Beta)
--------------------
![Screenshot_2020-10-16-22-44-36](/uploads/7edf89b7e672d23fb431252cb1ed5fc9/Screenshot_2020-10-16-22-44-36.jpg)Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40117WebGL extensions are not disabled anymore with Tor Browser based on >= ESR 782023-11-04T01:14:38ZGeorg KoppenWebGL extensions are not disabled anymore with Tor Browser based on >= ESR 78It seems the `webgl.disable-extensions` which we still set and which was
supposed to disable WebGL extensions is gone. The option to disable
those extensions got removed it seems [during a
refactoring](https://bugzilla.mozilla.org/show_b...It seems the `webgl.disable-extensions` which we still set and which was
supposed to disable WebGL extensions is gone. The option to disable
those extensions got removed it seems [during a
refactoring](https://bugzilla.mozilla.org/show_bug.cgi?id=1477756).
Thus, if one checks e.g. on https://webglreport.com/ extensions are
enabled now. We should
i. think about what we want to do now (should we write a patch to
disable them again?).
ii. go over our other WebGL prefs we set and check whether they are
still used.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/33971Document Authenticode code signing certificate renewal process2022-12-09T13:19:27ZGeorg KoppenDocument Authenticode code signing certificate renewal processWhile it is still fresh we should document the process of renewing our Windows code signing certificate.While it is still fresh we should document the process of renewing our Windows code signing certificate.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/core/arti/-/issues/481Use of `nf_conntimeout_clients` seems incorrect2023-06-13T17:43:00ZNick MathewsonUse of `nf_conntimeout_clients` seems incorrectInspecting C Tor and `padding-spec`, it appears that we're setting `unused_client_circ_timeout_while_learning_cbt` incorrectly. Right now it's set to `nf_conntimeout_clients`, which isn't supposed to be used for that.Inspecting C Tor and `padding-spec`, it appears that we're setting `unused_client_circ_timeout_while_learning_cbt` incorrectly. Right now it's set to `nf_conntimeout_clients`, which isn't supposed to be used for that.Arti 1.0.0: Ready for production useNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/440Discard consensus if certificates can't be found.2022-10-06T14:25:16ZNick MathewsonDiscard consensus if certificates can't be found.If we try many times to find the certificates for a given consensus, and everybody tells us 404, then it's possible we've been lied to about the signing keys. But currently arti will just keep looking for the certificates forever.
Two ...If we try many times to find the certificates for a given consensus, and everybody tells us 404, then it's possible we've been lied to about the signing keys. But currently arti will just keep looking for the certificates forever.
Two answers here are:
* remember where we got the consensus from, and ask that same source for the certificates we don't have. Mark it as very naughty if it can't tell us, and drop the consensus.
* if we try a lot of times to get the certificates for a consensus, and everybody tells us "no cert with that signing key", then discard the consensus or try to get a new one.Arti 1.0.0: Ready for production useNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/345Always build a circuit before calling ourselves "bootstrapped"?2022-03-01T17:30:54ZNick MathewsonAlways build a circuit before calling ourselves "bootstrapped"?In the current code, if we _start_ with a complete cached set of directory documents, it's possible for a TorClient to return from bootstrap() even if there is no network connection.
That's probably not what the user wants; maybe we sho...In the current code, if we _start_ with a complete cached set of directory documents, it's possible for a TorClient to return from bootstrap() even if there is no network connection.
That's probably not what the user wants; maybe we should also ensure that at least once circuit has built? Or possibly that should be optional.
This can be for %"Arti 1.0.0: Ready for production use"Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/311Extreme CPU usage2022-03-01T17:27:14ZmohixExtreme CPU usage<!--
* Use this issue template for reporting a new bug.
-->
### Summary
Im having multiple WAN ports which every 5 minutes the router switch between them in a round robin algorithmic way. This happen inside the router.
After WAN switch ...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
Im having multiple WAN ports which every 5 minutes the router switch between them in a round robin algorithmic way. This happen inside the router.
After WAN switch happen arti lose the connection with it peers which its completely normal but after trying to make new peers its CPU usage goes higher. After 7-8 switch arti use 100% of CPU. I guess there its some lock that prevents the lost connection to finish and destruct it, rather than its still trying to make the connection on the lost port.
### Steps to reproduce:
You dont need high configure system to test it. Just have two different internet WAN its enough.
1. Remove the ethernet WAN port from PC and put another ethernet WAN.
2. Wait until atri make new connections.
3. Repeat steep [1,2] for 10 times.
### What is the current bug behavior?
Using 100% of CPU usage
### What is the expected behavior?
CPU usage should be less than 1%
### Environment
- Version: Arti 0.0.4
- Operating system: Windows 11
- Install method: from git
- etc...
### Relevant logs and/or screenshots:
<details><summary>Log</summary>
←[2m2022-02-01T09:24:42.805661Z←[0m ←[33m WARN←[0m ←[2mtor_proto::circuit::reactor←[0m←[2m:←[0m Circ 2.5: having to enqueue cell due to backpressure: ChanCell { circid: CircId(2363215174), msg: Relay(Relay) }
←[2m2022-02-01T09:24:42.830781Z←[0m ←[33m WARN←[0m ←[2mtor_proto::circuit::reactor←[0m←[2m:←[0m Circ 2.5: having to enqueue cell due to backpressure: ChanCell { circid: CircId(2363215174), msg: Relay(Relay) }
←[2m2022-02-01T09:24:42.840138Z←[0m ←[33m WARN←[0m ←[2mtor_proto::circuit::reactor←[0m←[2m:←[0m Circ 2.5: having to enqueue cell due to backpressure: ChanCell { circid: CircId(2363215174), msg: Relay(Relay) }
←[2m2022-02-01T09:24:42.884217Z←[0m ←[33m WARN←[0m ←[2mtor_proto::circuit::reactor←[0m←[2m:←[0m Circ 2.5: having to enqueue cell due to backpressure: ChanCell { circid: CircId(2363215174), msg: Relay(Relay) }
←[2m2022-02-01T09:24:42.922146Z←[0m ←[33m WARN←[0m ←[2mtor_proto::circuit::reactor←[0m←[2m:←[0m Circ 2.5: having to enqueue cell due to backpressure: ChanCell { circid: CircId(2363215174), msg: Relay(Relay) }
←[2m2022-02-01T09:25:11.716475Z←[0m ←[33m WARN←[0m ←[2marti::proxy←[0m←[2m:←[0m connection exited with error: directory timed out
←[2m2022-02-01T09:25:11.745268Z←[0m ←[33m WARN←[0m ←[2marti::proxy←[0m←[2m:←[0m connection exited with error: directory timed out
←[2m2022-02-01T09:25:12.204730Z←[0m ←[33m WARN←[0m ←[2marti::proxy←[0m←[2m:←[0m connection exited with error: directory timed out
←[2m2022-02-01T09:27:47.633435Z←[0m ←[33m WARN←[0m ←[2marti::proxy←[0m←[2m:←[0m connection exited with error: Error while reading SOCKS handshake
←[2m2022-02-01T09:27:47.633433Z←[0m ←[33m WARN←[0m ←[2marti::proxy←[0m←[2m:←[0m connection exited with error: Error while reading SOCKS handshake
←[2m2022-02-01T09:27:47.643401Z←[0m ←[33m WARN←[0m ←[2marti::proxy←[0m←[2m:←[0m connection exited with error: Error while reading SOCKS handshake
</details>
### Possible fixes:
Restarting arti makes it normalArti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/201Always select paths from back to front?2022-03-01T17:30:43ZNick MathewsonAlways select paths from back to front?On #184, @mikeperry suggests that we should always pick paths in reverse order, from the last hop to the first. This prevents the following attack:
* The attacker makes us build a zillion circuits ending at a point they control.
* Th...On #184, @mikeperry suggests that we should always pick paths in reverse order, from the last hop to the first. This prevents the following attack:
* The attacker makes us build a zillion circuits ending at a point they control.
* The attacker notices which exit(s) we never use.
* The attacker infers that our Guard must be in the family of those exits.
This attack gets worse when we have onion services, since they provide a mechanism for an attacker to force you into building a zillion circuits.
An implementation for #183 would be necessary in order to implement back-to-front path selection correctly.
But before we move ahead: There is a related information leak to consider, if we do implement this defense without changes to our guard selection algorithm:
* Usually we use primary guard A.
* But when our exit or middle is in the same family as A, we choose guard B instead. If guard A and guard B are ruled out, then we choose guard C.
* From our choice of primary guard, a local observer can infer information about our paths.
Perhaps the solution to that information leak is to increase the `guard-n-primary-guards-to-use` parameter so that clients choose randomly among a few guards for each circuit, rather than trying to only use one? But changing _that_ parameter would roll back the benefits of [proposal 236](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/236-single-guard-node.txt). See also ["One Fast Guard for Life"](https://www-users.cse.umn.edu/~hoppernj/single_guard.pdf).Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41418Node information omitted from circuit popup (12.0a4)2022-12-09T17:41:37ZTornNode information omitted from circuit popup (12.0a4)Where before the Site Information popup under the favicon used to display the three nodes and their locations, and further relays if describing an .onion site, it now just reads "Tor Circuit", quite non-descriptively. Unless the node inf...Where before the Site Information popup under the favicon used to display the three nodes and their locations, and further relays if describing an .onion site, it now just reads "Tor Circuit", quite non-descriptively. Unless the node information is now intended to be concealed, seems like a mistake. Even if is an intentional change, there doesn't seem to be any point for it to just state "Tor Circuit" with no detail, as general use of Tor could be reasonably assumed.Sponsor 131 - Phase 3 - Major ESR 102 Migrationma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41408Onion authentication semantic and accessibility problems2022-12-09T16:00:50ZhenryOnion authentication semantic and accessibility problemsThe authentication popup:
1. When the popup shows it is read as a notification on screen readers. However, the notification begins with the onion address "<onion-address> is requesting that you authenticate", so the notification is a bu...The authentication popup:
1. When the popup shows it is read as a notification on screen readers. However, the notification begins with the onion address "<onion-address> is requesting that you authenticate", so the notification is a bunch of text noise before the relevant information is reached. There's not much we can do about onion sites unreadable names, but we could front the message with something more readable, like "An onion site is requesting that you authenticate. Learn more. Onion address: <onion-address>".
2. The invalid key warning (`#tor-clientauth-warning`) lacks semantics that show it as a warning and connected to the input, like `aria-errormessage`. The input is not marked as invalid.
The onion net error page (e.g. when cancelling authentication):
1. The diagram at the top of the page (`#onionErrorDiagramContainer`) lacks an equivalent description for screen readers. Currently you just get the text nodes with no context.
2. The rest of the page is lacking some semantic structure, but it comes from mozilla.
The "Onion Service Keys" dialog in preferences:
1. `#onionservices-savedkeys-errorMessage` could use something like `aria-live` to notify the user of errors.
2. The `#onionservices-savedkeys-tree` xul:table is lacking some accessibility features that a `role="grid"` would expect. But this comes from the xul:table implementation.
3. The table is very obscure to read. The onion sites and keys are just long random strings, so are very bad on screen readers, but also lack context for visual users as well because it is not easy to identify the onion site. I don't know if anything can be done about this.Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41295Android app - privacy issue: Removing of trackers2023-11-06T21:32:04ZbreeptAndroid app - privacy issue: Removing of trackersForwarded from:
https://github.com/guardianproject/tor-android/issues/83
Currently it seems there is an implementation of 3 trackers
* <b>Adjust</b>
* <b>Google Firebase Analytics</b>
* <b>Mozilla Telemetry</b>
See:
https://reports....Forwarded from:
https://github.com/guardianproject/tor-android/issues/83
Currently it seems there is an implementation of 3 trackers
* <b>Adjust</b>
* <b>Google Firebase Analytics</b>
* <b>Mozilla Telemetry</b>
See:
https://reports.exodus-privacy.eu.org/de/reports/268768
For app:
https://play.google.com/store/apps/details?id=org.torproject.torbrowser
Looking to the history report,
https://reports.exodus-privacy.eu.org/de/reports/search/org.torproject.torbrowser
it seems most of them were added during period of
August 2020 v68.12.0 (https://reports.exodus-privacy.eu.org/de/reports/144884)
and
November 2020 v10.0.3 (82.1.1-Release) (https://reports.exodus-privacy.eu.org/de/reports/152895)
Is there any chance to reduced these items?Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40571Windows copyright notices should contain Tor Project2023-08-25T23:13:38ZMark SmithWindows copyright notices should contain Tor ProjectWhile working on legacy/trac#16910, Kathy and I noticed that the copyright notices embedded within the browser executables on Windows (firefox.exe, updater.exe) have the same text as in Firefox. For consistency with Mac OS, we should use...While working on legacy/trac#16910, Kathy and I noticed that the copyright notices embedded within the browser executables on Windows (firefox.exe, updater.exe) have the same text as in Firefox. For consistency with Mac OS, we should use text like:
Copyright 2015 The Tor Project
or maybe we should change both platforms to use:
Copyright (c) 2015, The Tor Project, Inc.
For reference, the file Bundle-Data/Docs/Licenses/Tor.txt within our builders/tor-browser-bundle repo. contains the following copyright text:
Copyright (c) 2001-2004, Roger Dingledine
Copyright (c) 2004-2006, Roger Dingledine, Nick Mathewson
Copyright (c) 2007-2013, The Tor Project, Inc.
(we we are at it, we should also update the year there).Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40899Fix all of our usage of `app.support.baseURL`2023-10-03T16:42:04ZrichardFix all of our usage of `app.support.baseURL`So we cannot just point app.support.baseURL to our own manual and call it a day because mozilla uses this URL to point to various Firefox-specific support pages.
We need to audit these, and identify which ones need to point to tor-brows...So we cannot just point app.support.baseURL to our own manual and call it a day because mozilla uses this URL to point to various Firefox-specific support pages.
We need to audit these, and identify which ones need to point to tor-browser manual entries and which should go to Mozilla support pages.Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-bundle-testsuite/-/issues/40066Make tools/signing/nightly/sign-nightly sign mar files when there is no incre...2022-10-21T18:18:00ZboklmMake tools/signing/nightly/sign-nightly sign mar files when there is no incrementals`tools/signing/nightly/sign-nightly` currently check for the file `sha256sums-unsigned-build.incrementals.txt` to decide if a new version is ready to be signed. This means that when building incrementals failed, the mar files are not sig...`tools/signing/nightly/sign-nightly` currently check for the file `sha256sums-unsigned-build.incrementals.txt` to decide if a new version is ready to be signed. This means that when building incrementals failed, the mar files are not signed.Sponsor 131 - Phase 4 - Browser Release Managementboklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40568Set up Android signing token on the signing machine2023-08-22T19:44:55ZGeorg KoppenSet up Android signing token on the signing machineSponsor 131 - Phase 4 - Browser Release Management