The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-28T19:00:53Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25715Ubuntu bionic LTS freezes this month and currently contains Tor 0.3.2.x2020-07-28T19:00:53ZRoger DingledineUbuntu bionic LTS freezes this month and currently contains Tor 0.3.2.xTheir release schedule says that it will be a 5 year LTS, so supported until April 2023:
https://wiki.ubuntu.com/Releases
Bionic is on track to include Tor 0.3.2.10:
https://launchpad.net/ubuntu/bionic/+source/tor
But Tor 0.3.2.x is sc...Their release schedule says that it will be a 5 year LTS, so supported until April 2023:
https://wiki.ubuntu.com/Releases
Bionic is on track to include Tor 0.3.2.10:
https://launchpad.net/ubuntu/bionic/+source/tor
But Tor 0.3.2.x is scheduled to end-of-life in late 2018:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Listofreleases
So we are on track for 4.5 years of sadness for ubuntu users.
I see three possible paths forward:
* Inform Ubuntu but accept that they will stick to Tor 0.3.2, and plan to just have a miserable passive-aggressive existence with Ubuntu users for the coming years. :(
* Ask Ubuntu to switch back to Tor 0.2.9 (our LTS), which will be supported through the end of 2019. It is plausible that we would opt to continue supporting 0.2.9 for a while more after that too, depending on when our next LTS appears. (I believe our plan is to choose our next LTS based on Debian's schedule.)
* Make a deal with Ubuntu where they ship either 0.3.2 or 0.2.9 for now, but when our next LTS appears, they'll update to it. In the past we tried such a thing and it didn't go as smoothly as either side would have liked, but that doesn't mean the idea itself is a bad one.
I think we should work towards achieving option 2 or option 3, since option 1 would be unfortunate.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25714switch Travis to using Rust stable2020-06-27T13:53:45ZTaylor Yuswitch Travis to using Rust stableRight now our Travis use Rust nightly instead of stable. Now that we are standardizing on a stable Rust (see legacy/trac#24765), we should have Travis use stable so we catch accidental uses of nightly features.Right now our Travis use Rust nightly instead of stable. Now that we are standardizing on a stable Rust (see legacy/trac#24765), we should have Travis use stable so we catch accidental uses of nightly features.Tor: 0.3.4.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25713"DisableNetwork is set" log message in Tor Browser scares/confuses users2022-06-16T15:17:39ZRoger Dingledine"DisableNetwork is set" log message in Tor Browser scares/confuses usersWhen Tor Browser has trouble connecting, we tell users to go look at the logs. The first thing they see in their logs is something like
```
13/06/2017 11:31:29.600 [NOTICE] DisableNetwork is set. Tor will not make
or accept non-c...When Tor Browser has trouble connecting, we tell users to go look at the logs. The first thing they see in their logs is something like
```
13/06/2017 11:31:29.600 [NOTICE] DisableNetwork is set. Tor will not make
or accept non-control network connections. Shutting down all existing
connections.
```
and if they're hunting for a log message that gives them a hint about why Tor doesn't work, that one is easy to find and seems really related to why their tor might not work.
So we have this recurring event where users come to us and say "My Tor Browser isn't working, it says DisableNetwork is set."
Now, Tor Browser legitimately starts Tor with DisableNetwork set, so Tor Browser will have time to ask the user whether they want to use bridges or proxies or etc before their Tor starts interacting with the network. So "well stop using that option then" is hopefully not our best plan.
But I wonder if there is a smarter way to have that phrased in the logs, so users have a better chance of guessing correctly what is going on.
(Long term we want to not send Tor Browser users to go read Tor's logs. But we're not there yet either.)https://gitlab.torproject.org/tpo/core/tor/-/issues/25708[test] setenv() failure in util/expand_filename: test: environment corrupt; m...2020-07-28T18:59:52ZTrac[test] setenv() failure in util/expand_filename: test: environment corrupt; missing value for MAKEOVERWith tor commit 3df954549232bf5516ba5fce13c66a3ac91524a4 :
on FreeBSD 10.3-STABLE (r311284), FreeBSD version 1003511 libc seems to have trouble using setenv() and issues a warning about NULL pointer assigned to the MAKEOVER environment ...With tor commit 3df954549232bf5516ba5fce13c66a3ac91524a4 :
on FreeBSD 10.3-STABLE (r311284), FreeBSD version 1003511 libc seems to have trouble using setenv() and issues a warning about NULL pointer assigned to the MAKEOVER environment variable.
As a result, setenv() does not complete and the test fails:
```
util/expand_filename: test: environment corrupt; missing value for MAKEOVER
FAIL ../tor/src/test/test_util.c:1725: assert("/home/itv/" OP_EQ str): </home/itv/> vs </home/saper/>
[expand_filename FAILED]
```
This is almost certainly not a bug in tor, logging for further investigation.
**Trac**:
**Username**: saperTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25705Refactor circuit_build_failed to separate build vs path failures2020-06-27T13:53:45ZMike PerryRefactor circuit_build_failed to separate build vs path failuresWe should not give up on the network, our TLS conn, or our guard in the event of path failures (which can happen if we're low on mds, and/or if the user set a bunch of path-restricting torrc options).
I think this might want to be a bac...We should not give up on the network, our TLS conn, or our guard in the event of path failures (which can happen if we're low on mds, and/or if the user set a bunch of path-restricting torrc options).
I think this might want to be a backport. It should also handle legacy/trac#25347.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25692onion_extend_cpath: Non-fatal assertion info || client failed.2020-06-27T13:53:46ZNick Mathewsononion_extend_cpath: Non-fatal assertion info || client failed.When running "make test-network-all", I see a bunch of these errors:
```
Apr 02 18:46:57.375 [warn] Bug: Non-fatal assertion info || client failed in onion_extend_cpath at src/or/circuitbuild.c:2772. Stack trace: (on Tor 0.3.4.0-alpha-d...When running "make test-network-all", I see a bunch of these errors:
```
Apr 02 18:46:57.375 [warn] Bug: Non-fatal assertion info || client failed in onion_extend_cpath at src/or/circuitbuild.c:2772. Stack trace: (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(log_backtrace+0x43) [0x55a0c255ee03] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(tor_bug_occurred_+0xb9) [0x55a0c257a3c9] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(circuit_establish_circuit+0x732) [0x55a0c24b2ae2] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(circuit_launch_by_extend_info+0x8c) [0x55a0c24c487c] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(circuit_build_needed_circs+0x2e7) [0x55a0c24c4ef7] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(+0x8e078) [0x55a0c2430078] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /lib64/libevent-2.0.so.5(event_base_loop+0x7a9) [0x7f2fa8e2df19] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(do_main_loop+0x245) [0x55a0c2430bf5] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(tor_run_main+0x1015) [0x55a0c24330b5] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(tor_main+0x3a) [0x55a0c242b79a] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(main+0x19) [0x55a0c242b529] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /lib64/libc.so.6(__libc_start_main+0xea) [0x7f2fa7468f2a] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Bug: /home/nickm/src/tor/src/or/tor(_start+0x2a) [0x55a0c242b57a] (on Tor 0.3.4.0-alpha-dev 386116d52ac5f869)
Apr 02 18:46:57.375 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
```
I don't seem to get this on 0.3.3, and neither does Teor.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25691Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pi...2020-06-27T13:53:46ZteorBridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exitWhen running bridges-min and bridges+ipv6-min in chutney on macOS 10.13, Apple clang 9.0.0 with Xcode 9.2:
```
Apr 03 08:16:13.578 [info] circuit_predict_and_launch_new: Have 0 clean circs (0 internal), need another exit circ.
Apr 03 0...When running bridges-min and bridges+ipv6-min in chutney on macOS 10.13, Apple clang 9.0.0 with Xcode 9.2:
```
Apr 03 08:16:13.578 [info] circuit_predict_and_launch_new: Have 0 clean circs (0 internal), need another exit circ.
Apr 03 08:16:13.578 [info] choose_good_exit_server_general: Found 1 servers that might support 0/0 pending connections.
Apr 03 08:16:13.579 [info] choose_good_exit_server_general: Chose exit server '$2E832C796F35B96C3854941B01FF4E51E0968E24~test002r at 127.0.0.1'
Apr 03 08:16:13.580 [warn] tor_bug_occurred_: Bug: src/or/circuitbuild.c:2390: onion_pick_cpath_exit: Non-fatal assertion !(exit_ei == NULL) failed. (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.585 [warn] Bug: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit at src/or/circuitbuild.c:2390. Stack trace: (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.586 [warn] Bug: 0 tor 0x00665f83 log_backtrace + 67 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.587 [warn] Bug: 1 tor 0x006e0ad7 tor_bug_occurred_ + 503 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.587 [warn] Bug: 2 tor 0x0011843d circuit_establish_circuit + 18621 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.588 [warn] Bug: 3 tor 0x00186560 circuit_launch_by_extend_info + 992 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.589 [warn] Bug: 4 tor 0x0017f868 circuit_build_needed_circs + 3784 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.590 [warn] Bug: 5 tor 0x0044b33c second_elapsed_callback + 1468 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.591 [warn] Bug: 6 tor 0x0075b2f1 periodic_timer_cb + 129 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.592 [warn] Bug: 7 libevent-2.1.6.dylib 0x0104f6f3 event_process_active_single_queue + 1289 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.593 [warn] Bug: 8 libevent-2.1.6.dylib 0x0104bf12 event_base_loop + 1109 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.594 [warn] Bug: 9 tor 0x00449fd9 do_main_loop + 3289 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.595 [warn] Bug: 10 tor 0x00453990 tor_run_main + 704 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.596 [warn] Bug: 11 tor 0x006585a7 tor_main + 71 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.597 [warn] Bug: 12 tor 0x000a3546 main + 38 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.598 [warn] Bug: 13 libdyld.dylib 0xa75576e1 start + 1 (on Tor 0.3.4.0-alpha-dev 3df954549232bf55)
Apr 03 08:16:13.599 [info] circuit_mark_for_close_: Circuit 0 (id: 2) marked for close at src/or/circuitbuild.c:479 (orig reason: -2, new reason: 0)
Apr 03 08:16:13.600 [info] circuit_free_: Circuit 0 (id: 2) has been freed.
```
Other networks also log this bug but don't fail.
```
$ clang --version
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.3.0
...
```Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25687over-report of observed / self-measure bandwidth on fast hardware -- importa...2022-06-24T14:36:10Zstarlightover-report of observed / self-measure bandwidth on fast hardware -- important to torflow / peerflowHave observed that on fast hardware the maximum bandwidth estimate reported by `rep_hist_bandwidth_assess()` and published via `ri->bandwidthcapacity` is frequently overstated and have seen it go as high 160% of true physical bandwidth, ...Have observed that on fast hardware the maximum bandwidth estimate reported by `rep_hist_bandwidth_assess()` and published via `ri->bandwidthcapacity` is frequently overstated and have seen it go as high 160% of true physical bandwidth, stay there for days.
Connected today in my mind that this may be one of the larger causes of `torflow` misbehavior No control system will function correctly with bad input data and without question +60% qualifies as bad--GIGO.
Problem appears to have worsened with the arrival of KIST scheduler.
Have no idea why it occurs, but have see for years, with overrating appearing relative to absolute physical link speeds and relative to Linux `tc-police` rate limits.
Even `peerflow` when it arrives will require reliable measurement data to function properly.https://gitlab.torproject.org/tpo/core/tor/-/issues/25686Mystery bug causes relays to attempt many many descriptor publishes, with no ...2020-06-27T13:53:46ZRoger DingledineMystery bug causes relays to attempt many many descriptor publishes, with no X-Desc-Gen-Reason headerSometimes relays get into a state where they try to publish a new descriptor every second, and this state lasts for hours or days.
I instrumented moria1 to keep track of the X-Desc-Gen-Reason headers in each descriptor upload attempt:
`...Sometimes relays get into a state where they try to publish a new descriptor every second, and this state lasts for hours or days.
I instrumented moria1 to keep track of the X-Desc-Gen-Reason headers in each descriptor upload attempt:
```
diff --git a/src/or/directory.c b/src/or/directory.c
index c419b61..4570b20 100644
--- a/src/or/directory.c
+++ b/src/or/directory.c
@@ -5102,6 +5102,15 @@ directory_handle_command_post,(dir_connection_t *conn, const char *headers,
const char *msg = "[None]";
uint8_t purpose = authdir_mode_bridge(options) ?
ROUTER_PURPOSE_BRIDGE : ROUTER_PURPOSE_GENERAL;
+
+ {
+ char *genreason = http_get_header(headers, "X-Desc-Gen-Reason: ");
+ log_info(LD_DIRSERV,
+ "New descriptor post, because: %s",
+ genreason ? genreason : "not specified");
+ tor_free(genreason);
+ }
+
was_router_added_t r = dirserv_add_multiple_descriptors(body, purpose,
conn->base_.address, &msg);
tor_assert(msg);
```
And then I counted up the number of upload attempts of each type over the last two-ish weeks:
```
$ grep "New descriptor post, because:" moria1-info|cut -d: -f5-|sort|uniq -c
20685 bandwidth has changed
1 Chosen Or/DirPort changed
53191 config change
601 configured managed proxies
41663 DirPort found reachable
96 dns resolvers back
191 IP address changed
131619 not listed in consensus
1647625 not specified
31440 ORPort found reachable
8518 rotated onion key
28 set onion key
120487 time for new descriptor
156 Tor just started
25362 version listed in consensus is quite old
```
Now, the weird "not listed in consensus" and "version listed in consensus is quite old" ones are legacy/trac#25685.
But there are a huge number that are simply lacking this header. These tend to come from a relatively small number of relays that are just bombing me with publish attempts.
In fact, out of those 1647625 attempts that didn't provide a reason, nearly all of them got discarded:
```
$ grep -A1 "New descriptor post, because: not specified" moria1-info|grep "Not replacing descriptor"|wc -l
1645051
```
We should try to track down what bug on the relay side causes republishes without including a reason header. Maybe we do this by examining the code and looking for mistakes where a republish can happen without also setting the reason header?
See legacy/trac#3942 for a time long ago that we had problems with listing our reason. And see legacy/trac#21642 for where a lot of this analysis started.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25685Tor relays publish a new descriptor but authorities drop it because they thin...2020-06-27T13:53:46ZRoger DingledineTor relays publish a new descriptor but authorities drop it because they think it's only cosmetically different, and then the relay waits 18 more hours to publish, thus falling out of the consensusWe have a design flaw, or at least an impedance mismatch, in our descriptor publishing algorithm.
Relays publish a new descriptor when they think something has sufficiently changed (e.g. bandwidth, IP address, exit policy, etc) or when ...We have a design flaw, or at least an impedance mismatch, in our descriptor publishing algorithm.
Relays publish a new descriptor when they think something has sufficiently changed (e.g. bandwidth, IP address, exit policy, etc) or when 18 hours have passed.
Directory authorities accept the new descriptor when *they* think it has sufficiently changed. If they think it hasn't, they quietly drop it:
```
log_info(LD_DIRSERV,
"Not replacing descriptor from %s (source: %s); "
"differences are cosmetic.",
router_describe(ri), source);
```
The trouble comes when things get out of sync: the relay thinks it published recently so it is still early in its 18 hour timer, but the authorities discarded that descriptor. Then when the "current" descriptor becomes 24 hours old, it gets discarded, and the relay falls out of the consensus.
I don't have stats on how frequently this out-of-sync actually happens, but it's enough to have tickets filed about it (legacy/trac#23638) and it's enough to have confused/sad posts from relay operators about it every month:
https://lists.torproject.org/pipermail/tor-dev/2018-March/013030.html
https://lists.torproject.org/pipermail/tor-relays/2018-March/014764.html
We deployed a bandaid in 0.2.3.4-alpha (commit 1f4b694, legacy/trac#3327), that makes relays look in the consensus and publish a new descriptor more aggressively if they find they're not listed. That hack is apparently needed quite often: in legacy/trac#21642 I said "So 426 of our ~7300 relays stayed in the consensus in the last 12.5 hours because of this hack."
But I think we haven't actually explored whether the bandaid helps all of the relays stay in the consensus all of the time, or if there are still "holes" in it that mean some relays fall out sometimes. The reports above make me think that yes there are still holes.
Potential ways forward:
* Match up the descriptor upload timings, as seen by a dir auth, with the appearance of relays in the consensus. See how many of the relays publishing for reason "version listed in consensus is quite old" are missing any hours in the consensus.
* If there are some that fall out of the consensus entirely, think about ways to make the republish more aggressive and earlier, or if it is already more aggressive and earlier, figure out why it isn't sticking.
* Think about ways to make our relay-side decisions about "is it different enough" synchronize better with our dirauth-side decisions. Now that we're doing hourly consensus documents, can the dir auths be more lenient of similar-ish descriptors, because there's only one "winner" of a descriptor each hour? This poor synchronization is part of why we couldn't implement proposal 275 when we wanted to.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25682Obsolete Tor Core Encryption, Only use SHA3/ed25519/curve25519 for building C...2020-06-27T13:53:46ZTracObsolete Tor Core Encryption, Only use SHA3/ed25519/curve25519 for building Circuitsa) Better crypto (replaced SHA1/DH/RSA1024 with SHA3/ed25519/curve25519)
Don't allow New Tor nodes to build circuits with obsolete Tor Nodes unless they support the newer encryption version 0.3.2.9 - 2018-01-09
Only use the old crypto ...a) Better crypto (replaced SHA1/DH/RSA1024 with SHA3/ed25519/curve25519)
Don't allow New Tor nodes to build circuits with obsolete Tor Nodes unless they support the newer encryption version 0.3.2.9 - 2018-01-09
Only use the old crypto to resolve old .Onion honeypots...........
Only use SHA3/ed25519/curve25519 to build New 3 hop Circuits. This will provide better anon for hidden services which use the same transport system.
**Trac**:
**Username**: Anonyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25679Default for TOR_RUST_DEPENDENCIES is wrong?2020-06-27T13:53:46ZNick MathewsonDefault for TOR_RUST_DEPENDENCIES is wrong?Try building Tor using the tor-rust-dependencies submodule, without actually setting TOR_RUST_DEPENDENCIES. It's supposed to work, but it doesn't: it looks at the wrong directory.Try building Tor using the tor-rust-dependencies submodule, without actually setting TOR_RUST_DEPENDENCIES. It's supposed to work, but it doesn't: it looks at the wrong directory.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25678Clarify how ed25519 extended private keys are used in rend-spec-v3.txt2021-09-16T14:30:52ZGeorge KadianakisClarify how ed25519 extended private keys are used in rend-spec-v3.txtIn legacy/trac#24342 we started specifying how extended private keys are used in rend-spec-v3.txt but we didn't do it in a complete manner (see comment:9:ticket:24342).
We should improve the state of the spec on this regard.In legacy/trac#24342 we started specifying how extended private keys are used in rend-spec-v3.txt but we didn't do it in a complete manner (see comment:9:ticket:24342).
We should improve the state of the spec on this regard.https://gitlab.torproject.org/tpo/core/tor/-/issues/25677Tor startup crash with Sandbox 1 in torrc.d - sandbox_intern_string(): Bug: N...2020-06-27T13:53:47ZadrelanosTor startup crash with Sandbox 1 in torrc.d - sandbox_intern_string(): Bug: No interned sandbox parameter foundTor from deb.torproject.org. Inside Whonix 14.
`dpkg -l | grep tor`
```
ii tor 0.3.2.10-1~d90.stretch+1 amd64 anonymizing overlay network for TCP
```
```
user@host:~$...Tor from deb.torproject.org. Inside Whonix 14.
`dpkg -l | grep tor`
```
ii tor 0.3.2.10-1~d90.stretch+1 amd64 anonymizing overlay network for TCP
```
```
user@host:~$ cat /etc/tor/torrc
## Do not edit this file!
## Please create and add modifications to the following file instead:
## /usr/local/etc/torrc.d/50_user.conf
%include /etc/torrc.d/95_whonix.conf
user@host:~$ cat /etc/torrc.d/95_whonix.conf
## Do not edit this file!
## Please create and add modifications to the following file instead:
## /usr/local/etc/torrc.d/50_user.conf
%include /usr/local/etc/torrc.d/40_anon_connection_wizard.conf
%include /usr/local/etc/torrc.d/50_user.conf
user@host:~$ cat /usr/local/etc/torrc.d/40_anon_connection_wizard.conf
# This file is generated by and should ONLY be used by anon-connection-wizard.
# User configuration should go to /usr/local/etc/torrc.d/50_user.conf, not here. Because:
# 1. This file can be easily overwritten by anon-connection-wizard.
# 2. Even a single character change in this file may cause error.
# However, deleting this file will be fine since a new plain file will be generated the next time you run anon-connection-wizard.
DisableNetwork 0
user@host:~$ cat /usr/local/etc/torrc.d/50_user.conf
Sandbox 1
```
```
Mar 30 06:14:28 host Tor[5429]: Opening DNS listener on 10.137.11.1:5300
Mar 30 06:14:28 host Tor[5429]: Opening DNS listener on 127.0.0.1:5400
Mar 30 06:14:28 host Tor[5429]: Opening Transparent pf/netfilter listener on 10.137.11.1:9040
Mar 30 06:14:28 host Tor[5429]: Opening Transparent pf/netfilter listener on 127.0.0.1:9041
Mar 30 06:14:28 host Tor[5429]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Mar 30 06:14:28 host Tor[5429]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Mar 30 06:14:28 host Tor[5429]: Bootstrapped 0%: Starting
Mar 30 06:14:28 host Tor[5429]: Starting with guard context "default"
Mar 30 06:14:28 host Tor[5429]: Bootstrapped 80%: Connecting to the Tor network
Mar 30 06:14:28 host Tor[5429]: Signaled readiness to systemd
Mar 30 06:14:28 host Tor[5429]: Received reload signal (hup). Reloading config and resetting internal state.
Mar 30 06:14:28 host Tor[5429]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Mar 30 06:14:28 host Tor[5429]: Read configuration file "/etc/tor/torrc".
Mar 30 06:14:29 host Tor[5429]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/torrc.d/95_whonix.conf (on Tor 0.3.2.10 )
Mar 30 06:14:29 host systemd[1]: Started Anonymizing overlay network for TCP.
Mar 30 06:14:29 host Tor[5429]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/torrc.d/95_whonix.conf (on Tor 0.3.2.10 )
Mar 30 06:14:29 host Tor[5429]: Could not open "/etc/torrc.d/95_whonix.conf": Permission denied
Mar 30 06:14:29 host Tor[5429]: Error reading included configuration file or directory: "/etc/torrc.d/95_whonix.conf".
Mar 30 06:14:29 host Tor[5429]: Reading config failed--see warnings above. For usage, try -h.
Mar 30 06:14:29 host Tor[5429]: Restart failed (config error?). Exiting.
Mar 30 06:14:29 host systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
```Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25676When a client asks for a gzip-encoded consensus, the server sends zlib2020-07-28T18:58:26ZteorWhen a client asks for a gzip-encoded consensus, the server sends zlib```
$ curl -s -O --header "Accept-Encoding: gzip" 91.121.230.208:9030/tor/status-vote/current/consensus && file consensus
Accept-Encoding: gzip
Requested: status-vote/current/consensus
consensus: zlib compressed data
```
But when the cl...```
$ curl -s -O --header "Accept-Encoding: gzip" 91.121.230.208:9030/tor/status-vote/current/consensus && file consensus
Accept-Encoding: gzip
Requested: status-vote/current/consensus
consensus: zlib compressed data
```
But when the client asks for gzip-encoded descriptors, the server sends gzip:
```
Accept-Encoding: gzip
Requested: server/authority
authority: gzip compressed data, max compression, from Unix
```
See https://trac.torproject.org/projects/tor/ticket/25667#comment:11 for a full list of requested encodings, documents, and served formats.
I think this is a minor bug with no impact, because tor clients will decompress the zlib anyway. (I don't know if tor clients ever ask for gzip without zlib.)
But I'd like someone who knows the compression code better to confirm.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25675fix CID 14336432020-06-27T13:53:47ZTaylor Yufix CID 1433643Coverity found `control_free_all()` was accessing `flush_queued_event_pending` without locking. This was actually an old latent bug dating back to when we added multithreading to this queue, but Coverity somehow didn't notice the other ...Coverity found `control_free_all()` was accessing `flush_queued_event_pending` without locking. This was actually an old latent bug dating back to when we added multithreading to this queue, but Coverity somehow didn't notice the other unlocked accesses.Tor: 0.3.4.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25674relay: Improve connect failure cache lifetime with a backoff algorithm2020-07-28T18:59:07ZDavid Gouletdgoulet@torproject.orgrelay: Improve connect failure cache lifetime with a backoff algorithmWith ticket legacy/trac#24767, we now have a cache that tracks the relay to relay connection failures. We use that to avoid reconnecting to a relay that we know previously failed.
We could improve here with some sort of backoff algorith...With ticket legacy/trac#24767, we now have a cache that tracks the relay to relay connection failures. We use that to avoid reconnecting to a relay that we know previously failed.
We could improve here with some sort of backoff algorithm instead of the flat hardcoded 60 seconds waiting period.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25669Privcount: blinding and encryption should be finished up2021-09-16T14:30:52ZNick MathewsonPrivcount: blinding and encryption should be finished upWe're supposed to do this in 0.3.4. I don't know if there is anything here left to do, but in case there is (like merging to tor, testing more, etc) this is the master ticket.We're supposed to do this in 0.3.4. I don't know if there is anything here left to do, but in case there is (like merging to tor, testing more, etc) this is the master ticket.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25668Write a proposal for using two guards, not one2020-06-27T13:53:47ZNick MathewsonWrite a proposal for using two guards, not oneSee tor-dev discussion. This is a roadmapped item.See tor-dev discussion. This is a roadmapped item.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25667LZMA/ZSTD descriptor compression support2020-06-27T13:53:48ZDamian JohnsonLZMA/ZSTD descriptor compression supportHi lovely core tor folks. I've been working on Stem support for spec 278 which was merged in tor 0.3.1.1 but I'm struggling to find an example of it working in practice...
https://gitweb.torproject.org/torspec.git/commit/?id=1cb56af
htt...Hi lovely core tor folks. I've been working on Stem support for spec 278 which was merged in tor 0.3.1.1 but I'm struggling to find an example of it working in practice...
https://gitweb.torproject.org/torspec.git/commit/?id=1cb56af
https://gitweb.torproject.org/user/atagar/stem.git/commit/?h=compression
Moria1 is running tor 0.3.4.0 so it definitely should have lzma and zstd compression support, but when I query its dirport only the identity and deflate headers seem to work...
```
% curl --header "Accept-Encoding: identity" 128.31.0.39:9131/tor/server/fp/9695DFC35FFEB861329B9F1AB04C46397020CE31
router moria1 128.31.0.34 9101 0 9131
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABnxNAQS9ja600v/ZodOUiu7NepTkbPIOrFPgEVQE+03rGBtPAQAgBADKnR/C
2nhpr9UzJkkbPy83sqbfNh63VgFnCpkSTULAcq52z8xM7raRDCiTJTu/FK/BJGgE
dJcFQ8MgZJOuYgFKcMVyQ6j2FGbhDI0zQTK1+TAPNRG4ixiF7h7wqDT9Ugw=
-----END ED25519 CERT-----
master-key-ed25519 yp0fwtp4aa/VMyZJGz8vN7Km3zYet1YBZwqZEk1CwHI
platform Tor 0.3.4.0-alpha-dev on Linux
...
```
```
% curl --header "Accept-Encoding: deflate" 128.31.0.39:9131/tor/server/fp/9695DFC35FFEB861329B9F1AB04C46397020CE31
[ compressed data ]
```
```
% curl --header "Accept-Encoding: x-zstd" 128.31.0.39:9131/tor/server/fp/9695DFC35FFEB861329B9F1AB04C46397020CE31
[ uncompressed data, same as 'identity' ]
% curl --header "Accept-Encoding: x-tor-lzma" 128.31.0.39:9131/tor/server/fp/9695DFC35FFEB861329B9F1AB04C46397020CE31
[ uncompressed data, same as 'identity' ]
```Tor: 0.3.3.x-final