Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:54:04Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25323Create an official tor-rust-dependencies.git repository2020-06-27T13:54:04ZNick MathewsonCreate an official tor-rust-dependencies.git repositoryRight now, our tor-rust-dependencies repository lives in Sebastian's namespace. We should turn it into an official repository in the root namespace, and adjust our submodules config and our documentation accordingly.
We should also fig...Right now, our tor-rust-dependencies repository lives in Sebastian's namespace. We should turn it into an official repository in the root namespace, and adjust our submodules config and our documentation accordingly.
We should also figure out what our plan is for keeping the dependencies in it up-to-date.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25316Assertion failure in scale_active_circuits2020-06-27T13:54:05ZTracAssertion failure in scale_active_circuitsRelay 855BC2DABE24C861CD887DB9B2E950424B49FC34 crashed with the following log entries:
```
Feb 20 14:33:40.000 [err] tor_assertion_failed_(): Bug: ../src/or/circuitmux_ewma.c:711: scale_active_circuits: Assertion e->last_adjusted_tick ==...Relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 crashed with the following log entries:
```
Feb 20 14:33:40.000 [err] tor_assertion_failed_(): Bug: ../src/or/circuitmux_ewma.c:711: scale_active_circuits: Assertion e->last_adjusted_tick == pol->active_circuit_pqueue_last_recalibrated failed; aborting. (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: Assertion e->last_adjusted_tick == pol->active_circuit_pqueue_last_recalibrated failed in scale_active_circuits at ../src/or/circuitmux_ewma.c:711. Stack trace: (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42) [0x7f4b7ab65fb2] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x9f) [0x7f4b7ab80b3f] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(+0xe74b2) [0x7f4b7aac74b2] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(circuitmux_notify_xmit_cells+0xdb) [0x7f4b7aac5a7b] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(channel_flush_from_first_active_circuit+0x269) [0x7f4b7aa5b7d9] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(channel_flush_some_cells+0xe4) [0x7f4b7aaaf8d4] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(+0xbd369) [0x7f4b7aa9d369] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(+0xbb2a2) [0x7f4b7aa9b2a2] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x414) [0x7f4b7a0ee254] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(do_main_loop+0x255) [0x7f4b7aa35d75] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(tor_main+0x1e75) [0x7f4b7aa397d5] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(main+0x19) [0x7f4b7aa31539] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f4b79103ead] (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(+0x51589) [0x7f4b7aa31589] (on Tor 0.3.2.9 )
```
Relay runs on Debian wheezy. uname -a:
Linux 3.2.0-5-amd64 #1 SMP Debian 3.2.96-3 x86_64 GNU/Linux
Uptime before the crash was 23 days. Memory and CPU usage was normal:
```
Feb 20 12:55:12.000 [notice] Heartbeat: Tor's uptime is 23 days 17:59 hours, with 30352 circuits open. I've sent 20574.36 GB and received 20125.28 GB.
```
**Trac**:
**Username**: LogformeTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25313Sandbox: Caught a bad syscall attempt (syscall poll)2020-06-27T13:54:05ZcypherpunksSandbox: Caught a bad syscall attempt (syscall poll)
```
(Sandbox) Caught a bad syscall attempt (syscall poll)
/usr/bin/tor(+0x1a5baa)[0x560fee34ebaa]
/lib/x86_64-linux-gnu/libc.so.6(__poll+0x10)[0x7fd66246c690]
/lib/x86_64-linux-gnu/libc.so.6(__poll+0x10)[0x7fd66246c690]
/lib/x86_6...
```
(Sandbox) Caught a bad syscall attempt (syscall poll)
/usr/bin/tor(+0x1a5baa)[0x560fee34ebaa]
/lib/x86_64-linux-gnu/libc.so.6(__poll+0x10)[0x7fd66246c690]
/lib/x86_64-linux-gnu/libc.so.6(__poll+0x10)[0x7fd66246c690]
/lib/x86_64-linux-gnu/libc.so.6(+0x11b573)[0x7fd6624a8573]
/lib/x86_64-linux-gnu/libc.so.6(+0x11c189)[0x7fd6624a9189]
/lib/x86_64-linux-gnu/libc.so.6(+0x1187f2)[0x7fd6624a57f2]
/lib/x86_64-linux-gnu/libc.so.6(+0x118a3e)[0x7fd6624a5a3e]
/lib/x86_64-linux-gnu/libc.so.6(getpwnam_r+0x1cd)[0x7fd6624443ed]
/lib/x86_64-linux-gnu/libc.so.6(getpwnam+0x90)[0x7fd662443d20]
/usr/bin/tor(tor_getpwnam+0x29)[0x560fee3369e9]
/usr/bin/tor(check_private_dir+0x9f)[0x560fee3480bf]
/usr/bin/tor(create_keys_directory+0x34)[0x560fee29b924]
/usr/bin/tor(init_keys+0x89)[0x560fee2439d9]
/usr/bin/tor(do_main_loop+0x54)[0x560fee1fd5b4]
/usr/bin/tor(tor_run_main+0x275)[0x560fee1fef25]
/usr/bin/tor(tor_main+0x3a)[0x560fee1f836a]
/usr/bin/tor(main+0x19)[0x560fee1f80d9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fd6623ad2b1]
/usr/bin/tor(_start+0x2a)[0x560fee1f812a]
```
config
```
OfflineMasterKey 1
RunAsDaemon 0
Log notice syslog
OutboundBindAddress xxxxxx
SocksPort 0
User xxxx
DataDirectory xxxxx
ORPort xxxxxxx
ORPort xxxxxxxxx
OutboundBindAddress xxxxxxx
DirPort xxxxxxxxx
ControlSocket 0
CookieAuthentication 0
Sandbox 1
ExitRelay 0
ExitPolicy reject *:*
```
os: debian 9 on KVM
reproducible with:
0.3.2.9-1~d90.stretch+1
0.3.3.2-alpha-1~d90.stretch+1
0.3.4.0-alpha-dev-20180220T150525Z-1~d90.stretch+1Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25252Rust implementation of protover code deviates from C in some cases2020-06-27T13:54:08ZNick MathewsonRust implementation of protover code deviates from C in some casesTeor found some cases where the Rust protover code deviates from the C protover code. We should fix all of these in 0.3.3.Teor found some cases where the Rust protover code deviates from the C protover code. We should fix all of these in 0.3.3.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25251Fix TROVE-2018-004: bad consensus can trigger null pointer crash.2020-06-27T13:54:08ZNick MathewsonFix TROVE-2018-004: bad consensus can trigger null pointer crash.When checking their own versions against the subprotocol versions listed in a consensus document, Tor instances could be made to crash if the consensus was incorrectly formatted.
This is a low-severity bug, since it can only be exploite...When checking their own versions against the subprotocol versions listed in a consensus document, Tor instances could be made to crash if the consensus was incorrectly formatted.
This is a low-severity bug, since it can only be exploited by corrupting a majority of directory authorities. (And any attacker who can do that, can do far worse.)
We're tracking this one as TROVE-2018-004. It was present in 0.2.9.4-alpha and later. It is fixed in 0.2.9.15, 0.3.1.10, 0.3.2.10, and 0.3.3.3-alpha.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25250Infinite loop in Rust protover implementation (TROVE-2018-003)2020-06-27T13:54:09ZNick MathewsonInfinite loop in Rust protover implementation (TROVE-2018-003)Our rust protover implementation has a denial-of-service problem on certain inputs.
Found by Teor. Calling this a "low-severity", since by default it would be medium-severity, but the rust protover code is uncommonly used and experimental.Our rust protover implementation has a denial-of-service problem on certain inputs.
Found by Teor. Calling this a "low-severity", since by default it would be medium-severity, but the rust protover code is uncommonly used and experimental.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25249Spec/implementation deviation in C protover code2020-06-27T13:54:09ZNick MathewsonSpec/implementation deviation in C protover codeOur C protover code will reject any attempt to create a protover range ending with UINT32_MAX. But our spec says that we allow that.
I suggest that, since this case is basically unreasonable, we should amend the spec to reject it, and ...Our C protover code will reject any attempt to create a protover range ending with UINT32_MAX. But our spec says that we allow that.
I suggest that, since this case is basically unreasonable, we should amend the spec to reject it, and amend the code to reject it explicitly.
Found by Teor.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25248DoS mitgation: improve documentation2022-10-11T23:39:49ZcypherpunksDoS mitgation: improve documentation(some reason for opening this is: a relay operator seemed confused and started to modify the source instead of using these torrc settings)
https://lists.torproject.org/pipermail/tor-relays/2018-February/014503.html
building on top of le...(some reason for opening this is: a relay operator seemed confused and started to modify the source instead of using these torrc settings)
https://lists.torproject.org/pipermail/tor-relays/2018-February/014503.html
building on top of legacy/trac#25236
Lets add a high level overview of available DoS mitigations at the beginning of the section next to "The following options are useful only for a public relay. They control the Denial of Service mitigation subsystem."
as you did in the changelog already before going into the specific settings.
We could start by using a copy from your changelog:
https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=tor-0.3.3.2-alpha#n8
something like:
"
Tor has 3 build-in mitigation options that can be individually enabled/disabled and fine-tuned, but by default Tor directory authorities will define reasonable values for relays and no explicit configuration is required to make use of these protections.
The mitigations are:
* First: if a single client address makes too many concurrent connections (~~>100~~ "too many" is configurable via XXX), hang up on further connections.
* Second: if a
single client IP address (v4 and v6 or does it just work with IPv4?) makes circuits too quickly (more than 3 per
second, with an allowed burst of 90) while also having too many
connections open (3), refuse new create cells for the next while
(1-2 hours).
* Third: if a client asks to establish a rendezvous
point to you directly, ignore the request. These defenses can be
manually controlled by new torrc options, but relays will also
take guidance from consensus parameters, so there's no need to
configure anything manually.
"
instead of the static values add the config options in brackets.
https://www.torproject.org/docs/tor-manual-dev.html.en#DoSCircuitCreationEnabled
Does not say what 0 and 1 means. Maybe use the same wording as you use for most other boolean settings:
"If this option is set to 1, ...
* The section "DENIAL OF SERVICE MITIGATION OPTIONS" refers to the consensus
for default values, lets tell the operator how to find the current consensus values so he has actually some information where they can say "that value is to low for me my system is idle" or "oh that is not defined in consensus" -> legacy/trac#25236
will these values show on https://consensus-health.torprojec.org?Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25236dos: Document torrc default values in the man page when not in the consensus2022-10-11T23:39:48ZDavid Gouletdgoulet@torproject.orgdos: Document torrc default values in the man page when not in the consensusFrom:
https://trac.torproject.org/projects/tor/ticket/24902#comment:68From:
https://trac.torproject.org/projects/tor/ticket/24902#comment:68Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25226Circuit cell queue can fill up memory2022-10-11T23:39:48ZDavid Gouletdgoulet@torproject.orgCircuit cell queue can fill up memoryA relay operator just reported this on 0.3.3.2-alpha:
https://lists.torproject.org/pipermail/tor-relays/2018-February/014496.html
In a nutshell, the OOM fired up with these logs:
```
Feb 12 18:54:55 tornode2 Tor[6362]: We're low on me...A relay operator just reported this on 0.3.3.2-alpha:
https://lists.torproject.org/pipermail/tor-relays/2018-February/014496.html
In a nutshell, the OOM fired up with these logs:
```
Feb 12 18:54:55 tornode2 Tor[6362]: We're low on memory (cell queues total alloc: 1602579792 buffer total alloc: 1388544, tor compress total alloc: 1586784 rendezvous cache total alloc: 489909). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
Feb 12 18:54:56 tornode2 Tor[6362]: Removed 1599323088 bytes by killing 1 circuits; 39546 circuits remain alive. Also killed 0 non-linked directory connections.
```
Notice the ~1GB of cells for one single circuit? Somehow, there is an issue in tor that makes it possible to fill up the circuit cell queue while the scheduler is just not emptying that queue.
This really looks like the Sniper Attack: http://www.robgjansen.com/publications/sniper-ndss2014.pdfTor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25223dos: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed2022-10-11T23:39:48ZDavid Gouletdgoulet@torproject.orgdos: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failedI just got this report from a relay operator who got this on tor-0.3.3.2-alpha but that relay is an obfs4 bridge! DoS mitigation is not suppose to be running on bridges for now...
```
Feb 12 18:14:55.000 [notice] Tor 0.3.3.2-alpha (git-...I just got this report from a relay operator who got this on tor-0.3.3.2-alpha but that relay is an obfs4 bridge! DoS mitigation is not suppose to be running on bridges for now...
```
Feb 12 18:14:55.000 [notice] Tor 0.3.3.2-alpha (git-7b1d356bdb76607d) opening log file.
Feb 12 18:47:09.000 [warn] tor_bug_occurred_(): Bug: ../src/or/dos.c:679: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at ../src/or/dos.c:679. Stack trace: (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x44) [0x55e0314a7de4] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x55e0314c3479] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(channel_do_open_actions+0x1de) [0x55e0313e933e] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(channel_change_state_open+0x2a) [0x55e0313e93ba] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_state_change_on_orconn+0x102) [0x55e0313ee2f2] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(connection_or_set_state_open+0x22) [0x55e031437872] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x185) [0x55e0313ee535] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(+0x115a01) [0x55e031434a01] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(+0x10c52e) [0x55e03142b52e] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(+0x537ae) [0x55e0313727ae] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f6f4e6c55a0] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x2bc) [0x55e03137381c] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x275) [0x55e031374f25] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x55e03136e36a] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x55e03136e0d9] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f6f4cc9f2b1] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x55e03136e12a] (on Tor 0.3.3.2-alpha )
Feb 12 18:59:37.000 [warn] Onion service connection to [scrubbed] failed (connection refused)
```Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/252130.3.3.2-alpha - Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)...2020-06-27T13:54:10ZTrac0.3.3.2-alpha - Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)) failed.Running 2 tor relays, whilst restarting Tor going from 0.3.3.1-alpha-dev to 0.3.3.2-alpha one of the two nodes gave the following error for 3 other relays, being: Rea, fury and lowtideceviche
It's just running for 2 hours or so, the rem...Running 2 tor relays, whilst restarting Tor going from 0.3.3.1-alpha-dev to 0.3.3.2-alpha one of the two nodes gave the following error for 3 other relays, being: Rea, fury and lowtideceviche
It's just running for 2 hours or so, the remaining functionality seems OK.
Feb 11 20:01:04 tornode1 Tor[23044]: tor_bug_occurred_(): Bug: ../src/or/policies.c:1008: fascist_firewall_choose_address_node: Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)) failed. (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)) failed in fascist_firewall_choose_address_node at ../src/or/policies.c:1008. Stack trace: (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(log_backtrace+0x44) [0x55a3a4d5bde4] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x55a3a4d77479] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(fascist_firewall_choose_address_node+0x182) [0x55a3a4c47682] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(extend_info_from_node+0x12f) [0x55a3a4caaa7f] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(+0xed980) [0x55a3a4cc0980] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x261) [0x55a3a4cc0eb1] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(connection_ap_attach_pending+0x1a8) [0x55a3a4ce2808] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(do_main_loop+0x399) [0x55a3a4c278f9] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(tor_run_main+0x275) [0x55a3a4c28f25] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(tor_main+0x3a) [0x55a3a4c2236a] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(main+0x19) [0x55a3a4c220d9] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f6eb6b052b1] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(_start+0x2a) [0x55a3a4c2212a] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Could not choose valid address for Rea
Feb 11 20:01:04 tornode1 Tor[23044]: Could not make a one-hop connection to $8DCB8A8CD726EBCE5CCC90581EB7A695D6B09904. Discarding this circuit.
**Trac**:
**Username**: sjcjonkerTor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25202Check the calculations in cc_stats_refill_bucket using non fatal assertions2022-10-11T23:39:48ZteorCheck the calculations in cc_stats_refill_bucket using non fatal assertionsIn legacy/trac#25128, we removed an incorrect non-fatal assertion in cc_stats_refill_bucket() to silence a warning:
```
/* This function is not allowed to make the bucket count smaller */
tor_assert_nonfatal(new_circuit_bucket_count ...In legacy/trac#25128, we removed an incorrect non-fatal assertion in cc_stats_refill_bucket() to silence a warning:
```
/* This function is not allowed to make the bucket count smaller */
tor_assert_nonfatal(new_circuit_bucket_count >= stats->circuit_bucket);
```
But we could have fixed the check instead, and added another check:
```
/* This function is not allowed to make the bucket count larger than the burst value */
tor_assert_nonfatal(new_circuit_bucket_count <= dos_cc_circuit_burst);
/* This function is not allowed to make the bucket count smaller, unless it is
* decreasing it to a newly configured, lower burst value. We allow the bucket to
* stay the same size, in case the circuit rate is zero. */
tor_assert_nonfatal(new_circuit_bucket_count >= stats->circuit_bucket ||
new_circuit_bucket_count == dos_cc_circuit_burst);
```
We could be even more clever, and skip parts of the function if the rate is zero. That's probably unnecessary. I'll think about it.
I should get a chance to turn this into a proper branch over the next week or so. If someone else wants to do it before then, go for it!Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25193dos: Avoid blacklisting Exit relays2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgdos: Avoid blacklisting Exit relaysIt is possible to do "tor-in-tor" meaning a tor client connection can exit the network and come back at a Guard node.
And if this happens to be detected by the DoS subsystem, we'll blacklist the Exit relay for a while. That is *NOT* goo...It is possible to do "tor-in-tor" meaning a tor client connection can exit the network and come back at a Guard node.
And if this happens to be detected by the DoS subsystem, we'll blacklist the Exit relay for a while. That is *NOT* good.
Now that we have legacy/trac#25183, we can lookup the inbound address to learn if we know it. And if we do, don't consider it a potential malicious client that we need to look at.
That is one part of the solution, the second part is legacy/trac#2667 so we actually prevent reentry from Exit but that part won't be backported just yet (if ever).
This work will be part of legacy/trac#24902 so once merge_ready, it will be merged into my branch `ticket24902_029_05`.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25192change of bandwidth accounting intveral from 4 to 24 hours results in unreaso...2020-06-27T13:54:11Zstarlightchange of bandwidth accounting intveral from 4 to 24 hours results in unreasonable memory consumptionThe recent change of relay bandwidth reporting has increased the related memory consumption on a mid-size relay from about 200MB to about 1.2GB (i.e. a sixfold increase). The memory dedicated to this function has become unreasonably la...The recent change of relay bandwidth reporting has increased the related memory consumption on a mid-size relay from about 200MB to about 1.2GB (i.e. a sixfold increase). The memory dedicated to this function has become unreasonably large.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25183Implement a way to tell if an IP address is a known relay2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgImplement a way to tell if an IP address is a known relayFor the DoS mitigation subsystem (legacy/trac#24902), we need a way to lookup the connection address and *quickly* know if it is a known relay or not. This is also needed for legacy/trac#2667 which would prevent Exit to reenter the netwo...For the DoS mitigation subsystem (legacy/trac#24902), we need a way to lookup the connection address and *quickly* know if it is a known relay or not. This is also needed for legacy/trac#2667 which would prevent Exit to reenter the network.
nickm has started a branch to have IP addresses with bloom filter: `address_set_029`.
Next step is to use that and bridge it with the nodelist so we can lookup an IP address and learn if it is known or not (not get the `node_t` back, that would require more work and probably lose in performance).Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25171Clarify 'recognized' field in tor-spec2021-07-22T16:21:37ZDamian JohnsonClarify 'recognized' field in tor-specOur tor-spec left me pretty mystified what the 'recognized' field actually was. It discussed what to do when it was zero, but not what the field *was* or what non-zero meant. Thankfully Roger filled me in over tasty, tasty pizza.
Patch ...Our tor-spec left me pretty mystified what the 'recognized' field actually was. It discussed what to do when it was zero, but not what the field *was* or what non-zero meant. Thankfully Roger filled me in over tasty, tasty pizza.
Patch available in the 'recognized' branch of my repo...
https://gitweb.torproject.org/user/atagar/torspec.git/commit/?h=recognizedTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25163rephist: Remove unused counters in or_history_t2020-06-27T13:54:12ZDavid Gouletdgoulet@torproject.orgrephist: Remove unused counters in or_history_tThe rephist subsystem seems to track EXTEND cells attempt (on the client side) but the overall results of this is not used except in `rep_hist_dump_stats()`. This is the only use of `link_history_t` also afaict. See:
```
void rep_hist_n...The rephist subsystem seems to track EXTEND cells attempt (on the client side) but the overall results of this is not used except in `rep_hist_dump_stats()`. This is the only use of `link_history_t` also afaict. See:
```
void rep_hist_note_extend_succeeded(const char *from_name,
const char *to_name);
void rep_hist_note_extend_failed(const char *from_name, const char *to_name);
```
Furthermore, tor tracks downtime and uptime of relays but actually never use that information anywhere. See:
```
void rep_hist_note_connect_failed(const char* nickname, time_t when);
void rep_hist_note_connect_succeeded(const char* nickname, time_t when);
void rep_hist_note_disconnect(const char* nickname, time_t when);
void rep_hist_note_connection_died(const char* nickname, time_t when);
```
The side effect of this is that we keep adding objects to the `history_map` that are wasting memory and never used in the end except when we dump statistics.
By removing this, we would cleanup quite a bit of code and effectively make the `or_history_t` object *ONLY* useful to directory authorities for relay reachability tracking.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25148Make geoip_client_cache_total_allocation() use geoip_client_history_cache_size2020-06-27T13:54:13ZDavid Gouletdgoulet@torproject.orgMake geoip_client_cache_total_allocation() use geoip_client_history_cache_sizeIn commit `4d812e29b9b1ec88`, we forgot to make the function returning the total allocation return the counter instead of going over all entries which hugs the CPU like crazy.In commit `4d812e29b9b1ec88`, we forgot to make the function returning the total allocation return the counter instead of going over all entries which hugs the CPU like crazy.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25128Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circui...2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgBug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failedI changed the `DoSCircuitCreationBurst` value in my torrc and this BUG() was triggered:
```
Feb 02 21:52:55.902 [warn] tor_bug_occurred_(): Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= s...I changed the `DoSCircuitCreationBurst` value in my torrc and this BUG() was triggered:
```
Feb 02 21:52:55.902 [warn] tor_bug_occurred_(): Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failed. (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failed in cc_stats_refill_bucket at src/or/dos.c:312. Stack trace: (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: /root/git/tor/src/or/tor(log_backtrace+0x42) [0x557248c2bbd2] (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: /root/git/tor/src/or/tor(tor_bug_occurred_+0xb9) [0x557248c46f69] (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: /root/git/tor/src/or/tor(dos_cc_new_create_cell+0x263) [0x557248bf1e63] (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
```
This is because of:
```
/* This function is not allowed to make the bucket count smaller */
tor_assert_nonfatal(new_circuit_bucket_count >= stats->circuit_bucket);
```
We actually can make it smaller if the Burst or Rate is changed at runtime.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org