Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:54:22Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24952channel: channel_tls_get_remote_addr_method() should return the "real_addr" o...2020-06-27T13:54:22ZDavid Gouletdgoulet@torproject.orgchannel: channel_tls_get_remote_addr_method() should return the "real_addr" of the connectionThe accurate address of a connection is `real_addr`, not the `addr` member.
Lets make `channel_tls_get_remote_addr_method()` return the content of `real_addr` instead.The accurate address of a connection is `real_addr`, not the `addr` member.
Lets make `channel_tls_get_remote_addr_method()` return the content of `real_addr` instead.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24119channel_rsa_id_group_set_badness spends a lot of time in malloc/free2020-06-27T13:55:05ZAlex Xuchannel_rsa_id_group_set_badness spends a lot of time in malloc/freein particular, a very large proportion (~25%) of allocations made seem to be "temporary", i.e. an allocation is made and then freed before any other allocations are made. possibly a portion of these are due to the second loop, but I was ...in particular, a very large proportion (~25%) of allocations made seem to be "temporary", i.e. an allocation is made and then freed before any other allocations are made. possibly a portion of these are due to the second loop, but I was wondering if it is possible that the function is called with an empty list, and if that is a problem.
regardless, I have written a patch to use ht instead of only smartlists, which should very slightly increase the memory usage and moderately decrease the CPU usage in this function.Tor: 0.3.3.x-finalAlex XuAlex Xuhttps://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/25912CID 1435130: Incorrect expression (COPY_PASTE_ERROR)2020-06-27T13:53:38ZGeorge KadianakisCID 1435130: Incorrect expression (COPY_PASTE_ERROR)Seems like legacy/trac#23693 caused the following coverity warning:
```
** CID 1435130: Incorrect expression (COPY_PASTE_ERROR)
/src/or/router.c: 153 in dup_onion_keys()
________________________________________________________________...Seems like legacy/trac#23693 caused the following coverity warning:
```
** CID 1435130: Incorrect expression (COPY_PASTE_ERROR)
/src/or/router.c: 153 in dup_onion_keys()
________________________________________________________________________________________________________
*** CID 1435130: Incorrect expression (COPY_PASTE_ERROR)
/src/or/router.c: 153 in dup_onion_keys()
147 tor_assert(key);
148 tor_assert(last);
149 tor_mutex_acquire(key_lock);
150 if (onionkey)
151 *key = crypto_pk_copy_full(onionkey);
152 else
>>> CID 1435130: Incorrect expression (COPY_PASTE_ERROR)
>>> "last" in "*last = NULL" looks like a copy-paste error.
153 *last = NULL;
154 if (lastonionkey)
155 *last = crypto_pk_copy_full(lastonionkey);
156 else
157 *last = NULL;
158 tor_mutex_release(key_lock);
```
Perhaps this new `*last = NULL;` should have been `*key = NULL`.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23100Circuit Build Timeout needs to count hidden service circuits2020-06-27T13:55:59ZMike PerryCircuit Build Timeout needs to count hidden service circuitsThe Circuit Build Timeout code currently ignores all circuits with a desired_path_len other than 3. This causes it not to count hidden service circuits of longer path lengths.
When we change the path selection for Proposal247/#9001, we ...The Circuit Build Timeout code currently ignores all circuits with a desired_path_len other than 3. This causes it not to count hidden service circuits of longer path lengths.
When we change the path selection for Proposal247/#9001, we are going to want to count those circuits, because we want the circuit build timeout to prune 20% of Prop247 circuits, too. If we omit those circuits from the CBT calculation, we risk timing out either too few, too many, or even *all* of them.
The simplest way to fix this is to change circuit_timeout_want_to_count_circ() to decide to count every circuit once it has completed 3 hops, even if it plans to build more.
We may also want to alter the timeout application in circuit_expire_building(), depending on the prop247 implementation we choose. In some versions of the proposal, we can end up creating what are technically 5 hop paths (though these topologies were not very popular in Wilmington).Tor: 0.3.3.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23114Circuit Build Timeout should apply at circuit completion2020-06-27T13:55:57ZMike PerryCircuit Build Timeout should apply at circuit completionBack when the CBT code was first written, circuit build times were around 10 seconds. This meant it was fine to check if the timeout had passed in circuit_expire_building(), which was called once per second.
However, now that the typica...Back when the CBT code was first written, circuit build times were around 10 seconds. This meant it was fine to check if the timeout had passed in circuit_expire_building(), which was called once per second.
However, now that the typical timeout is more like 2 seconds or less, we actually let a significantly larger fraction of circuits through by waiting for this once-per-second callback.
The fix is to switch the purpose of circuits as they are being built and/or opened to MEASUREMENT circuits as soon as they pass the timeout, but before use. This will cause us to actually discard the proper fraction of slow paths.Tor: 0.3.3.x-finalMike PerryMike Perryhttps://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/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/24318Clarify that the RelayBandwidth* options exclude directory fetches by relays2021-07-22T16:21:37ZteorClarify that the RelayBandwidth* options exclude directory fetches by relaysTwice in the last few months, I have explained to relay operators that RelayBandwidthRate/Burst includes directory fetches from the relay by clients. But they do not include directory fetches by the relay (from authorities or other relay...Twice in the last few months, I have explained to relay operators that RelayBandwidthRate/Burst includes directory fetches from the relay by clients. But they do not include directory fetches by the relay (from authorities or other relays), because that is considered "client" activity.
We should clarify in the man page, because it clearly causes some confusion.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23874Clear the address when node_get_prim_orport() returns early2021-09-16T14:31:39ZteorClear the address when node_get_prim_orport() returns earlyThis is a memory safety thing.This is a memory safety thing.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26271client failed in onion_extend_cpath on Illumos/JoyentSmartOS2020-06-27T13:53:18ZTracclient failed in onion_extend_cpath on Illumos/JoyentSmartOSTor 0.3.3.6 (git-7dd0813e783ae16e) running on SunOS with Libevent 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
on SunOS 5.11 joyent_20180524T002819Z i86pc i386 i86pc Solaris
and getting lots of these:
```
...Tor 0.3.3.6 (git-7dd0813e783ae16e) running on SunOS with Libevent 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
on SunOS 5.11 joyent_20180524T002819Z i86pc i386 i86pc Solaris
and getting lots of these:
```
Jun 02 19:18:57.000 [warn] tor_bug_occurred_(): Bug: src/or/circuitbuild.c:2772: onion_extend_cpath: Non-fatal assertion info || client failed. (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: Non-fatal assertion info || client failed in onion_extend_cpath at src/or/circuitbuild.c:2772. Stack trace: (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'log_backtrace+0x47 [0x5cf7e7] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'tor_bug_occurred_+0xbb [0x5ea9db] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'circuit_establish_circuit+0x8bb [0x51954b] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'circuit_launch_by_extend_info+0x84 [0x52c7b4] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'circuit_build_needed_circs+0x2f6 [0x52ce76] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'second_elapsed_callback+0x3b8 [0x4916c8] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/lib/libevent-2.1.so.6.0.2'event_process_active_single_queue+0x372 [0xfffffc7fec883c32] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/lib/libevent-2.1.so.6.0.2'event_base_loop+0x5bf [0xfffffc7fec88471f] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'do_main_loop+0x214 [0x492184] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'tor_run_main+0x26d [0x49367d] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'tor_main+0x42 [0x48cbf2] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'main+0x1e [0x48caae] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'_start_crt+0x83 [0x48c913] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Bug: /opt/local/bin/tor'_start+0x18 [0x48c878] (on Tor 0.3.3.6 7dd0813e783ae16e)
Jun 02 19:18:57.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
```
I already checked legacy/trac#25692 but it seems the fix is already part of 3.3.6 7dd0813e783ae16e. "make test" ran with 0 errors, as well as the compile.
**Trac**:
**Username**: ruebezahlTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23827Clients/Relays: Use IPv6 Addresses from microdesc consensus2020-06-27T13:55:19ZteorClients/Relays: Use IPv6 Addresses from microdesc consensusClient/Relay Implementation for legacy/trac#20916.
We need to use the IPv6 addresses from consensuses with versions that implement legacy/trac#23826, and ignore microdesc IPv6 addresses.Client/Relay Implementation for legacy/trac#20916.
We need to use the IPv6 addresses from consensuses with versions that implement legacy/trac#23826, and ignore microdesc IPv6 addresses.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24946connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_...2020-06-27T13:54:23ZRoger Dingledineconnection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failedOn my onion service, I now get:
```
Jan 19 18:24:30.165 [warn] connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed. The purpose on the circuit was Hidden service: Uploading HS descriptor; it was in...On my onion service, I now get:
```
Jan 19 18:24:30.165 [warn] connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed. The purpose on the circuit was Hidden service: Uploading HS descriptor; it was in state open, path_state new. (on Tor 0.3.3.0-alpha-dev ef148638a1d3b312)
```
It looks like the clause in question is
```
}
if (circ->purpose != CIRCUIT_PURPOSE_C_GENERAL &&
circ->purpose != CIRCUIT_PURPOSE_C_MEASURE_TIMEOUT &&
circ->purpose != CIRCUIT_PURPOSE_PATH_BIAS_TESTING) {
log_warn(LD_BUG, "circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed. "
"The purpose on the circuit was %s; it was in state %s, "
"path_state %s.",
circuit_purpose_to_string(circ->purpose),
circuit_state_to_string(circ->state),
CIRCUIT_IS_ORIGIN(circ) ?
pathbias_state_to_string(TO_ORIGIN_CIRCUIT(circ)->path_state) :
"none");
}
```
and I'm suspecting that legacy/trac#23101 wanted to add a line here.Tor: 0.3.3.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24826consensus diffs stall Tor Browser launch for at least 20s or break it entirel...2020-06-27T13:54:30ZGeorg Koppenconsensus diffs stall Tor Browser launch for at least 20s or break it entirely if compiled with --enable-expensive-hardeningIn legacy/trac#22341 we are thinking about picking up LZMA- and Zstandard-support for consensus diffs.
For LZMA-compressed diffs I often encounter boostrap delays of at least 20s like this:
```
Dec 26 21:01:18.000 [debug] HTTP body from...In legacy/trac#22341 we are thinking about picking up LZMA- and Zstandard-support for consensus diffs.
For LZMA-compressed diffs I often encounter boostrap delays of at least 20s like this:
```
Dec 26 21:01:18.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was labeled as LZMA compressed, and it seems to be LZMA compressed.
Dec 26 21:01:38.000 [info] handle_response_fetch_consensus(): Applied consensus diff (size 482897) from server 'XX.XX.XX.XX:9001', resulting in a new consensus document (size 1903167).
```
But, worse, it might even break Tor Browser bootstrap entirely when blocking a Tor Launcher `GETCONF` call (throwing an exception as Tor Launcher thinks tor is not working) like so:
```
Dec 30 23:54:54.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was labeled as LZMA compressed, and it seems to be LZMA compressed.
Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError: s.split is not a function
Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError: s.split is not a function
[12-30 22:54:55] TorLauncher DBUG: readTorSettings ----------------------------------------------
[12-30 22:54:55] TorLauncher DBUG: Sending Tor command: GETCONF UseBridges
[12-30 22:55:10] TorLauncher NOTE: Exception on control port [Exception... "Component returned failure code: 0x804b000e (NS_ERROR_NET_TIMEOUT) [nsIBinaryInputStream.readBytes]" nsresult: "0x804b000e (NS_ERROR_NET_TIMEOUT)" location: "JS frame :: jar:file:///home/thomas/Arbeit/TBB/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/tor-launcher@torproject.org.xpi!/components/tl-protocol.js :: TorProtocolService.prototype._torReadLine :: line 920" data: no]
```Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24427Consider using other mach_*_time() functions for monotonic time on OSX2020-06-27T13:54:50ZNick MathewsonConsider using other mach_*_time() functions for monotonic time on OSXAs of OSX 10.9, there is a `mach_approximate_time()` which looks at first glance like it might be suitable for use as our `monotime_coarse`.
As of OSX 10.12, there are `mach_continuous_absolute_time()` and `mach_continuous_approximate_t...As of OSX 10.9, there is a `mach_approximate_time()` which looks at first glance like it might be suitable for use as our `monotime_coarse`.
As of OSX 10.12, there are `mach_continuous_absolute_time()` and `mach_continuous_approximate_time()`, which are supposed to keep counting while the system is sleeping.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23271control_auth_cookie isn't deleted when tor stops2020-06-27T13:55:52Zyurivict271control_auth_cookie isn't deleted when tor stopsWhen tor is stopped gracefully ('service stop tor' on FreeBSD), it leaves the file /var/db/tor/control_auth_cookie.
Due to the sensitive nature of this file, it should be only present when tor runs and deleted once it stops gracefully.When tor is stopped gracefully ('service stop tor' on FreeBSD), it leaves the file /var/db/tor/control_auth_cookie.
Due to the sensitive nature of this file, it should be only present when tor runs and deleted once it stops gracefully.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26170Core Tor releases typo2021-07-22T16:20:51ZTracCore Tor releases typoIt says 0.3.3 end of life is on `On or after Mar 22, 2018` but that is the day that it should be released.
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases?version=40
**Trac**:
**Username**: Dbryrtfb...It says 0.3.3 end of life is on `On or after Mar 22, 2018` but that is the day that it should be released.
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases?version=40
**Trac**:
**Username**: DbryrtfbcbhgfTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24543Coverity CID 1425733: Calling "hs_parse_address" without checking return value2020-06-27T13:54:46ZAlexander Færøyahf@torproject.orgCoverity CID 1425733: Calling "hs_parse_address" without checking return valueIn /src/or/hs_control.c: 225 in `hs_control_hspost_command()` we call `hs_parse_address()` without checking the return address.In /src/or/hs_control.c: 225 in `hs_control_hspost_command()` we call `hs_parse_address()` without checking the return address.Tor: 0.3.3.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24552Coverity CID 1425934: FORWARD_NULL in circuit_stream_is_being_handled()2020-06-27T13:54:45ZAlexander Færøyahf@torproject.orgCoverity CID 1425934: FORWARD_NULL in circuit_stream_is_being_handled()Coverity detected the following error:
```
src/or/circuituse.c: 1025 in circuit_stream_is_being_handled():
Null pointer dereferences (FORWARD_NULL)
Comparing "conn" to null implies that "conn" might be null.
```Coverity detected the following error:
```
src/or/circuituse.c: 1025 in circuit_stream_is_being_handled():
Null pointer dereferences (FORWARD_NULL)
Comparing "conn" to null implies that "conn" might be null.
```Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13605Create a client/relay-side ReducedExitPolicy2020-06-27T14:02:18ZMike PerryCreate a client/relay-side ReducedExitPolicyWe should have an "ExitPolicy Reduced" or "ReducedExitPolicy 1" torrc option for relay operators to more easily opt in to https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy.
We have a lot of people doing this on an ad-h...We should have an "ExitPolicy Reduced" or "ReducedExitPolicy 1" torrc option for relay operators to more easily opt in to https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy.
We have a lot of people doing this on an ad-hoc basis. We should make it official.Tor: 0.3.3.x-final