Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:29:27Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29481Cleanup bridgedb.conf and bridgedb.crontab2020-06-13T18:29:27ZDavid Gouletdgoulet@torproject.orgCleanup bridgedb.conf and bridgedb.crontabThe production `bridgedb.conf` needs to be cleaned up due to several outdated config in there.The production `bridgedb.conf` needs to be cleaned up due to several outdated config in there.Matthew FinkelMatthew Finkelhttps://gitlab.torproject.org/legacy/trac/-/issues/29079Minor bandwidth file spec updates2020-06-13T15:36:47ZteorMinor bandwidth file spec updatesThe terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n96The terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n96Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29029Make "tried to establish rendezvous on non-OR circuit" into a protocol warning2020-06-13T15:36:32ZteorMake "tried to establish rendezvous on non-OR circuit" into a protocol warningThere's nothing that relay operators can do to fix it.There's nothing that relay operators can do to fix it.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28992Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion ...2020-06-13T15:36:17ZtraumschuleBug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed.(likely follow-up of #28669)
```
Jan 04 06:53:53.620 [notice] Your system clock just jumped 21357 seconds forward; assuming established circuits no longer work.
Jan 04 06:55:05.286 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_c...(likely follow-up of #28669)
```
Jan 04 06:53:53.620 [notice] Your system clock just jumped 21357 seconds forward; assuming established circuits no longer work.
Jan 04 06:55:05.286 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:05.287 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.522 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.523 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
J
Jan 04 06:55:56.569 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.570 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
J
Jan 04 06:55:56.613 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.615 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
...
Jan 04 08:48:21.767 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.772 [warn] Bug: Non-fatal assertion !(ip == NULL) failed in send_introduce1 at ../src/feature/hs/hs_client.c:571. Stack trace: (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x65) [0x681d35] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xbd) [0x67d55d] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(hs_client_send_introduce1+0x23c) [0x58070c] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x797) [0x514317] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(connection_ap_attach_pending+0x171) [0x517b61] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(hs_client_receive_rendezvous_acked+0x82) [0x580d92] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(rend_process_relay_cell+0x235) [0x5cb345] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0xa0c04) [0x532c04] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x38a) [0x53515a] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(command_process_cell+0x181) [0x515111] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x34a) [0x4f9cea] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x8beed) [0x51deed] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x4a931) [0x4dc931] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(connection_handle_read+0x9a4) [0x4e6784] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x5ab79) [0x4ecb79] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/lib/i386-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7d1) [0xb7619681] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_libevent_run_event_loop+0x30) [0x61dfe0] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(do_main_loop+0xc5) [0x4edfe5] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(run_tor_main_loop+0x1ce) [0x4d996e] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_run_main+0x11c5) [0x4dad25] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_main+0x3f) [0x4d7ebf] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(main+0x35) [0x4d7a15] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb6f65b41] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x45a71) [0x4d7a71] (on Tor 0.4.0.0-alpha-dev )
```Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28698When circuit times are fixed, they can't be "relaxed"2020-06-13T15:35:04ZteorWhen circuit times are fixed, they can't be "relaxed"In #28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that they make se...In #28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that they make sense:
https://github.com/torproject/tor/blob/b058f64cc002b44e6dd48616ca3163a01c3f3e14/src/core/or/circuituse.c#L591
I think relaxed_timeout is meaningless when circuit_build_times_disabled() is true, but that's another issue.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28582Document the load-balancing goal for sbws2020-06-13T15:34:30ZteorDocument the load-balancing goal for sbwsWe should include a section early in the bandwidth spec that documents the load balancing goal for sbws.
Here's my initial draft:
```
Bandwidth scanners should have a well-defined network equilibrium goal.
For sbws and Torflow without ...We should include a section early in the bandwidth spec that documents the load balancing goal for sbws.
Here's my initial draft:
```
Bandwidth scanners should have a well-defined network equilibrium goal.
For sbws and Torflow without PID control, the network equilibrium goals are:
1. clients experience reasonably consistent performance
2. clients experience performance that is as fast as possible, without compromising goal 1
These performance goals include both throughput and latency.
For Torflow with PID control, the goal was:
1. Each relay has exactly the same spare capacity for an additional stream
This goal was unachievable because Tor did not provide enough feedback on circuit failure.
These non-goals are common suggestions:
1. Bandwidth is allocated equally across relays
2. All relay bandwidth is used
These goals are unachievable, because they conflict with the consistent client performance goal.
```
Based on mike's response from this thread:
```
I believe quite strongly that even if the Tor network gets faster on
average, if this comes at the cost of increased performance variance,
user experience and perceived speed of Tor will be much worse. There's
nothing more annoying than a system that is *usually* fast enough to do
what you need it to do, but fails to be fast enough for that activity at
unpredictable times.
```
https://lists.torproject.org/pipermail/tor-dev/2018-August/013419.htmlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28569Mark outdated dirservers in reasonably live consensuses2020-06-13T15:34:28ZteorMark outdated dirservers in reasonably live consensusesIf we have a reasonably live consensus, then most of our dirservers should still be caching all the microdescriptors in it.
Reasonably live consensuses are up to a day old. But microdescriptors expire 7 days after the last consensus tha...If we have a reasonably live consensus, then most of our dirservers should still be caching all the microdescriptors in it.
Reasonably live consensuses are up to a day old. But microdescriptors expire 7 days after the last consensus that referenced them.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28568Stop running stem's unit tests in Tor's stem test2020-06-13T15:34:28ZteorStop running stem's unit tests in Tor's stem testAs noted by atagar in:
https://trac.torproject.org/projects/tor/ticket/28552#comment:4
We can use --integ rather than --all.As noted by atagar in:
https://trac.torproject.org/projects/tor/ticket/28552#comment:4
We can use --integ rather than --all.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28533bridgesdb: replace the message to mail support with a link to the documentation2020-06-13T18:29:19Zemmapeelbridgesdb: replace the message to mail support with a link to the documentationIn the first page of bridges db there is a message at the end:
My bridges don't work! I need help!
Where we say the users to write to support immediately. I propose to change it for a message pointing to https://tb-manual.torproject.or...In the first page of bridges db there is a message at the end:
My bridges don't work! I need help!
Where we say the users to write to support immediately. I propose to change it for a message pointing to https://tb-manual.torproject.org/bridges/ to reduce the workload of the support team.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/27194Reject protover extra commas in protover2020-06-13T15:29:36ZTracReject protover extra commas in protoverLike how it handles spaces, `protover.c` rejects leading commas (`Link=,1-5` or `Link=,`) while it accepts and ignores extra commas elsewhere (`Link=1-5,` and `Link=1,,,2-5` are valid).
The Rust version accepts and ignores all extra com...Like how it handles spaces, `protover.c` rejects leading commas (`Link=,1-5` or `Link=,`) while it accepts and ignores extra commas elsewhere (`Link=1-5,` and `Link=1,,,2-5` are valid).
The Rust version accepts and ignores all extra commas, including leading commas.
**Trac**:
**Username**: cyberpunksTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25669Privcount: blinding and encryption should be finished up2020-06-13T15:28:44ZNick 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/legacy/trac/-/issues/2509424902 fix breaks on clang2020-06-13T15:21:23ZTaylor Yu24902 fix breaks on clanghttps://travis-ci.org/torproject/tor/jobs/335395212#L1716
```
src/or/dos.c:277:40: error: implicit conversion loses integer precision: 'long'
to 'uint32_t' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
num_token = elapsed_tim...https://travis-ci.org/torproject/tor/jobs/335395212#L1716
```
src/or/dos.c:277:40: error: implicit conversion loses integer precision: 'long'
to 'uint32_t' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
num_token = elapsed_time_last_refill * circuit_rate;
~ ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
```Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24736Clear the address when fascist_firewall_choose_address_base() can't find an a...2020-06-13T15:19:29ZteorClear the address when fascist_firewall_choose_address_base() can't find an addressWe should do this as a precaution, so we're not re-using an uninitialised address.
This is similar to #23874.We should do this as a precaution, so we're not re-using an uninitialised address.
This is similar to #23874.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/24679Remove custom weights from each fallback in the fallback list2020-06-13T16:06:12ZteorRemove custom weights from each fallback in the fallback listThis makes the fallback list 1 byte smaller per fallback, or ~150 bytes.This makes the fallback list 1 byte smaller per fallback, or ~150 bytes.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/24600Add fallback nicknames to the file, so stem can use them2020-06-13T16:06:10ZteorAdd fallback nicknames to the file, so stem can use themWe should do this in a machine-readable comment, to avoid inflating the tor binary with useless data.We should do this in a machine-readable comment, to avoid inflating the tor binary with useless data.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/24048Document which onion service stats include v3 onion services2020-06-13T18:09:11ZteorDocument which onion service stats include v3 onion servicesWe should document which metrics stats include v2 and v3 onion services:
The unique onion addresses stat is v2 only:
https://metrics.torproject.org/hidserv-dir-onions-seen.html
(See #23126 for a ticket to add v3 support)
But the onion ...We should document which metrics stats include v2 and v3 onion services:
The unique onion addresses stat is v2 only:
https://metrics.torproject.org/hidserv-dir-onions-seen.html
(See #23126 for a ticket to add v3 support)
But the onion service traffic includes v2 and v3:
https://metrics.torproject.org/hidserv-rend-relayed-cells.html
(See #24047 for a ticket to split the total into v2 and v3)teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23828Authorities: Remove IPv6 addresses from microdescriptors2020-06-13T15:15:44ZteorAuthorities: Remove IPv6 addresses from microdescriptorsWhen #23826 is locked in, we should remove IPv6 addresses from microdescs.When #23826 is locked in, we should remove IPv6 addresses from microdescs.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23826Authorities: Put Relay IPv6 addresses in the microdesc consensus2020-06-13T15:15:43ZteorAuthorities: Put Relay IPv6 addresses in the microdesc consensusAuthority Implementation for #20916Authority Implementation for #20916Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23818Make v2 and v3 single onion services retry all failed intro and rend connecti...2020-06-13T15:44:30ZteorMake v2 and v3 single onion services retry all failed intro and rend connections with a 3-hop pathThis makes a single onion service connect via an entry that it can reach when connections fail.This makes a single onion service connect via an entry that it can reach when connections fail.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23589Stop assuming that every extend_info contains an IPv4 address in get_lspecs_f...2020-06-13T15:14:21ZteorStop assuming that every extend_info contains an IPv4 address in get_lspecs_from_extend_info()addr can be an IPv6 addressaddr can be an IPv6 addressTor: 0.3.2.x-finalteorteor