Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:17:03Zhttps://gitlab.torproject.org/legacy/trac/-/issues/24167connection_check_event: Bug: Event missing on connection2020-06-13T15:17:03ZTracconnection_check_event: Bug: Event missing on connectionHi everybody
The following bug appeared:
connection_check_event: Bug: Event missing on connection
It's before hand a #23751 bug which is re-opened for it.
```
Tor 0.3.2.3-alpha (git-023d756bfc04c244) running on FreeBSD with Libevent ...Hi everybody
The following bug appeared:
connection_check_event: Bug: Event missing on connection
It's before hand a #23751 bug which is re-opened for it.
```
Tor 0.3.2.3-alpha (git-023d756bfc04c244) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.4, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.3.2.
```
Tor memory is about 5 GB according to:
```
MaxMemInQueues 5 GB
```
```
Nov 06 20:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 2:59 hours, with 89916 circuits open. I've sent 6246.15 GB and received 6171.99 GB.
Nov 06 20:45:27.000 [notice] Circuit handshake stats since last time: 31997/31997 TAP, 402465/402465 NTor.
Nov 06 20:45:27.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 297718 v4 connections; and received 2284 v1 connections, 47407 v2 connections, 113778 v3 connections, and 907883 v4 connections.
Nov 06 21:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 3:59 hours, with 156766 circuits open. I've sent 6284.75 GB and received 6211.71 GB.
Nov 06 21:45:27.000 [notice] Circuit handshake stats since last time: 34286/34286 TAP, 399076/399076 NTor.
Nov 06 21:45:27.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 298544 v4 connections; and received 2290 v1 connections, 47654 v2 connections, 114327 v3 connections, and 911591 v4 connections.
Nov 06 22:32:42.000 [warn] connection_check_event: Bug: Event missing on connection 0x80f227b00 [OR;open]. socket=-1. linked=0. is_dns_request=0. Marked_for_close=src/or/connection.c:3894 (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: Backtrace attached.. Stack trace: (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x11a2cd8 <log_backtrace+0x48> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x1071f21 <connection_is_reading+0x1c1> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x1071870 <connection_start_reading+0x30> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x1127408 <connection_bucket_refill+0x9a8> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x1073c8d <handle_signals+0xc2d> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x801b38d3e <event_base_assert_ok_nolock_+0xbce> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x801b34cfe <event_base_loop+0x50e> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x1072eb5 <do_main_loop+0x575> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x10752a9 <tor_main+0xe9> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x1070d09 <main+0x19> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:32:42.000 [warn] Bug: 0x1070c01 <_start+0x1a1> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 06 22:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 4:59 hours, with 221777 circuits open. I've sent 6323.37 GB and received 6252.10 GB.
Nov 06 22:45:27.000 [notice] Circuit handshake stats since last time: 97470/97470 TAP, 379601/379601 NTor.
Nov 06 22:45:27.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 299180 v4 connections; and received 2303 v1 connections, 47866 v2 connections, 114911 v3 connections, and 915142 v4 connections.
Nov 06 23:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 6:00 hours, with 87446 circuits open. I've sent 6350.85 GB and received 6278.68 GB.
Nov 06 23:45:27.000 [notice] Circuit handshake stats since last time: 21046/21046 TAP, 409042/409042 NTor.
Nov 06 23:45:27.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 300082 v4 connections; and received 2314 v1 connections, 48042 v2 connections, 115432 v3 connections, and 918682 v4 connections.
Nov 07 00:45:27.000 [notice] Heartbeat: Tor's uptime is 9 days 6:59 hours, with 298896 circuits open. I've sent 6373.37 GB and received 6302.57 GB.
Nov 07 00:45:27.000 [notice] Circuit handshake stats since last time: 206885/206885 TAP, 394540/394540 NTor.
Nov 07 00:45:27.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 300924 v4 connections; and received 2326 v1 connections, 48242 v2 connections, 115999 v3 connections, and 922124 v4 connections.
Nov 07 01:25:47.000 [warn] connection_check_event: Bug: Event missing on connection 0x80fac4980 [OR;open]. socket=-1. linked=0. is_dns_request=0. Marked_for_close=src/or/connection.c:3894 (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: Backtrace attached.. Stack trace: (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x11a2cd8 <log_backtrace+0x48> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x1071f21 <connection_is_reading+0x1c1> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x1071870 <connection_start_reading+0x30> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x1127408 <connection_bucket_refill+0x9a8> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x1073c8d <handle_signals+0xc2d> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x801b38d3e <event_base_assert_ok_nolock_+0xbce> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x801b34cfe <event_base_loop+0x50e> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x1072eb5 <do_main_loop+0x575> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x10752a9 <tor_main+0xe9> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x1070d09 <main+0x19> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:25:47.000 [warn] Bug: 0x1070c01 <_start+0x1a1> at /usr/local/bin/tor (on Tor 0.3.2.3-alpha 023d756bfc04c244)
Nov 07 01:27:51.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Nov 07 01:27:52.000 [notice] Removed 824368 bytes by killing 519528 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections.
Nov 07 01:27:55.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Nov 07 01:27:55.000 [notice] Removed 528 bytes by killing 163 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections.
Nov 07 01:27:55.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Nov 07 01:27:55.000 [notice] Removed 528 bytes by killing 170 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections.
Nov 07 01:27:55.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Nov 07 01:27:55.000 [notice] Removed 528 bytes by killing 455 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections.
```
Cheers !
**Trac**:
**Username**: FelixixTor: 0.2.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23856Reduce relay bandwidth stats interval to 24 hours2022-02-17T17:35:05ZteorReduce relay bandwidth stats interval to 24 hoursWe want to do this to reduce the efficiency of guard discovery attacks.We want to do this to reduce the efficiency of guard discovery attacks.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18710dnsserv.c asserts when no supported questions are requested2020-06-13T14:55:59ZTracdnsserv.c asserts when no supported questions are requestedThe patch for #10268 has a simple crasher that is easily exploited from the network if DNSPort is open to a LAN (e.g., if you are transparent proxying).
As [ticket:10268 #comment:11 andrea] hinted at, the added "if (!q) q = req->questio...The patch for #10268 has a simple crasher that is easily exploited from the network if DNSPort is open to a LAN (e.g., if you are transparent proxying).
As [ticket:10268 #comment:11 andrea] hinted at, the added "if (!q) q = req->questions[i];" to the for loop ensures that "q" is always set to the first question, even if it's unsupported. In which case, the "if (!q)" check for NOTIMPL is dead code. Ultimately, you will eventually hit the "tor_assert" that was added to the "else" branch. Additionally, the "switch" block switches on "req->questions[i]->type", but the assignment to "supported_q" is "q" (which is always the first question) instead of "req->questions[i]", so it doesn't actually pick the first supported question -- it always picks the first question.
**Trac**:
**Username**: geekmugTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16360tor_main continues after failed crypto_early_init in tor_init2020-06-13T14:46:51Zteortor_main continues after failed crypto_early_init in tor_initA typo in the return value from `tor_init` means that if `crypto_early_init` fails, `tor_main` can continue running, rather than returning with an error value.
This bug was introduced in commit `d3fb846d8c98` possibly related to feature...A typo in the return value from `tor_init` means that if `crypto_early_init` fails, `tor_main` can continue running, rather than returning with an error value.
This bug was introduced in commit `d3fb846d8c98` possibly related to feature #4900, first released in 0.2.5.2-alpha.
Given it's a very simple fix, where tor continues to run half-initialised, we might want to backport it.
I'll post a branch very soon.Tor: 0.2.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/15919How to set up obfsproxy between client and server using tor2020-06-13T14:45:48ZTracHow to set up obfsproxy between client and server using torHi
I have tried the below link to set up an obfsproxy between my tor client in Iran and another server outside Iran.
http://cyberside.net.ee/sibul/projects/obfsproxy.html.en
Unfortunately the instructions are vague and no client and ser...Hi
I have tried the below link to set up an obfsproxy between my tor client in Iran and another server outside Iran.
http://cyberside.net.ee/sibul/projects/obfsproxy.html.en
Unfortunately the instructions are vague and no client and server side difference can you advise how I cna set it up.
**Trac**:
**Username**: h.safeTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15205There's something fishy in OSX's checked strlcat.2020-06-13T14:44:03ZNick MathewsonThere's something fishy in OSX's checked strlcat.Have a look at https://opensource.apple.com/source/Libc/Libc-1044.1.2/secure/strlcat_chk.c .
When it checks to see whether the destination buffer overlaps with the input buffer in the second case, it isn't checking whether the input ove...Have a look at https://opensource.apple.com/source/Libc/Libc-1044.1.2/secure/strlcat_chk.c .
When it checks to see whether the destination buffer overlaps with the input buffer in the second case, it isn't checking whether the input overlaps with the actual buffer that *will* be written; it's checking whether the input overlaps with the destination buffer, _plus the extra space after the end of the destination buffer that would be written if there were enough room for the whole input._
I believe the second overlap check should be something more like:
```
__chk_overlap(dest, len, src, len - initial_dstlen - 1);
```
To do:
* Check whether any of the BSDs have this problem.
* Check whether older OSXs have this problem.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15088Add the wait4() syscall to the seccomp sandbox2020-06-13T14:43:55ZTracAdd the wait4() syscall to the seccomp sandboxTor version 0.2.5.10 seems to call wait4() upon receiving SIGHUP, and this violates the seccomp sandbox rules in sandbox.c, crashing the tor process.
Trace from tor's log on debug loglevel, right after `/etc/init.d/tor reload`:
```
====...Tor version 0.2.5.10 seems to call wait4() upon receiving SIGHUP, and this violates the seccomp sandbox rules in sandbox.c, crashing the tor process.
Trace from tor's log on debug loglevel, right after `/etc/init.d/tor reload`:
```
============================================================ T= 1425215692
(Sandbox) Caught a bad syscall attempt (syscall wait4)
/usr/bin/tor(+0x12f4f1)[0x4273cf44f1]
/lib64/libc.so.6(waitpid+0x1a)[0x3423957b1da]
/lib64/libc.so.6(waitpid+0x1a)[0x3423957b1da]
/usr/bin/tor(notify_pending_waitpid_callbacks+0x4a)[0x4273cf42da]
/usr/bin/tor(process_signal+0x4ad)[0x4273bfb96d]
/usr/lib64/libevent-2.0.so.5(event_base_loop+0x99e)[0x3423a111a6e]
/usr/bin/tor(do_main_loop+0x1ad)[0x4273bfa77d]
/usr/bin/tor(tor_main+0x1875)[0x4273bfd755]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x342394e2d55]
/usr/bin/tor(+0x31c49)[0x4273bf6c49]
Mar 01 16:14:52.000 [info] cpuworker_main(): read request failed. Exiting.
```
The patch is as simple as adding wait4() to the whitelist:
```
diff -Naur tor-0.2.5.10/src/common/sandbox.c tor-0.2.5.10.new/src/common/sandbox.c
--- tor-0.2.5.10/src/common/sandbox.c
+++ tor-0.2.5.10.new/src/common/sandbox.c
@@ -119,6 +119,7 @@
SCMP_SYS(epoll_wait),
SCMP_SYS(fcntl),
SCMP_SYS(fstat),
+ SCMP_SYS(wait4),
#ifdef __NR_fstat64
SCMP_SYS(fstat64),
#endif
```
**Trac**:
**Username**: sanicTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14261Directory authority refuses vote fetch with "Too much data received from dire...2020-06-13T14:41:58ZRoger DingledineDirectory authority refuses vote fetch with "Too much data received from directory connection"My directory authority just failed to make a consensus this round, and its notice-level logs include:
```
Jan 17 13:52:31.570 [notice] We're missing votes from 8 authorities (14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 E8A9C45EDE6D711294FAD...My directory authority just failed to make a consensus this round, and its notice-level logs include:
```
Jan 17 13:52:31.570 [notice] We're missing votes from 8 authorities (14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 ED03BB616EB2F60BEC80151114BB25CEF515B226 585769C78764D58426B8B52B6651A5A71137189A 80550987E1D626E3EBA5E5E75A458DE0626D088C 49015F787433103580E3B66A1707A00E60F2D15B EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97 23D15D965BC35114467363C165C4F724B64B4F66). Asking every other authority for a copy.
Jan 17 13:52:33.134 [warn] Too much data received from directory connection (154.35.32.5): denial of service attempt, or you need to upgrade?
Jan 17 13:52:34.187 [warn] Too much data received from directory connection (131.188.40.189): denial of service attempt, or you need to upgrade?
Jan 17 13:52:37.068 [warn] Too much data received from directory connection (194.109.206.212): denial of service attempt, or you need to upgrade?
Jan 17 13:52:38.146 [warn] Too much data received from directory connection (208.83.223.34): denial of service attempt, or you need to upgrade?
Jan 17 13:52:41.339 [warn] Too much data received from directory connection (86.59.21.38): denial of service attempt, or you need to upgrade?
Jan 17 13:52:44.722 [warn] Too much data received from directory connection (193.23.244.244): denial of service attempt, or you need to upgrade?
Jan 17 13:53:23.528 [warn] Too much data received from directory connection (171.25.193.9): denial of service attempt, or you need to upgrade?
```
It looks like our current limit of 10MB is too low for fetching all votes at once?
(I guess a second question is: did we really mean for Tor to ask for 10+ megabytes from each of 8 places in parallel?)Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14220Suppress warnings for dual declaration in srtp.h2020-06-13T14:41:54ZNick MathewsonSuppress warnings for dual declaration in srtp.hOpenSSL has a function declared twice in the srtp.h header.
```
18:36:32 In file included from /srv/jenkins-workspace/workspace/tor-ci-mingwcross-0.2.5/ARCHITECTURE/i386/SUITE/jessie/UPSTREAM/include/openssl/ssl.h:1392:0,
18:36:32 ...OpenSSL has a function declared twice in the srtp.h header.
```
18:36:32 In file included from /srv/jenkins-workspace/workspace/tor-ci-mingwcross-0.2.5/ARCHITECTURE/i386/SUITE/jessie/UPSTREAM/include/openssl/ssl.h:1392:0,
18:36:32 from src/common/tortls.c:36:
18:36:32 /srv/jenkins-workspace/workspace/tor-ci-mingwcross-0.2.5/ARCHITECTURE/i386/SUITE/jessie/UPSTREAM/include/openssl/srtp.h:142:26: error: redundant redeclaration of 'SSL_get_selected_srtp_profile' [-Werror=redundant-decls]
18:36:32 SRTP_PROTECTION_PROFILE *SSL_get_selected_srtp_profile(SSL *s);
18:36:32 ^
18:36:32 /srv/jenkins-workspace/workspace/tor-ci-mingwcross-0.2.5/ARCHITECTURE/i386/SUITE/jessie/UPSTREAM/include/openssl/srtp.h:139:26: note: previous declaration of 'SSL_get_selected_srtp_profile' was here
18:36:32 SRTP_PROTECTION_PROFILE *SSL_get_selected_srtp_profile(SSL *s);
18:36:32 ^
18:36:33 cc1: all warnings being treated as errors
```
I fixed this warning in master but it should get a changes file, so I'm giving it a bug number.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14142A 2-letter torrc file containing "Vi" causes tor to crash2020-06-13T14:41:38ZteorA 2-letter torrc file containing "Vi" causes tor to crashThe parsing of the `VirtualAddrNetworkIPv[46]` options crashes when the line or file ends after the option itself. (The IPv4? option can be abbreviated to "Vi").
This is an easy fix that involves checking for the empty string early on, ...The parsing of the `VirtualAddrNetworkIPv[46]` options crashes when the line or file ends after the option itself. (The IPv4? option can be abbreviated to "Vi").
This is an easy fix that involves checking for the empty string early on, before we assert on it in the parsing code.
Discovered using afl-fuzz with a custom tor binary that parses a torrc file from standard input (and doesn't do much else). This kind of fuzzing would be easier to conduct using a test harness, rather than using the entire tor binary.Tor: 0.2.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/14128GETINFO bw-samples to give recent BW events2020-06-13T14:41:34ZNick MathewsonGETINFO bw-samples to give recent BW events#13988 raises the interval at which bandwidth measurements are sampled. That's a pain for arm, which wants to use this information to prepopulate the bandwidth graph.
atagar asks for a means to get similar information from the last 1-5...#13988 raises the interval at which bandwidth measurements are sampled. That's a pain for arm, which wants to use this information to prepopulate the bandwidth graph.
atagar asks for a means to get similar information from the last 1-5 minutes.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14125can't parse bandwidth file2020-06-13T14:41:33Zweasel (Peter Palfrader)can't parse bandwidth fileHi,
my authority is unable to correctly parse the bw file created by my bwauthority:
```
[warn] Incomplete line in bandwidth file: "node_id=$4BCE1492221439B9C836FF5129BB2B548DB0FEE6 bw=2760 nick=0snowden4president measured_at=141873378...Hi,
my authority is unable to correctly parse the bw file created by my bwauthority:
```
[warn] Incomplete line in bandwidth file: "node_id=$4BCE1492221439B9C836FF5129BB2B548DB0FEE6 bw=2760 nick=0snowden4president measured_at=1418733785 updated_at=1418733785 pid_error=-0.000288722464561 pid_error_sum=-0.000288722464561 pid_bw=2764001 pid_delta=-0.0532977795585 circ_fail=0.333333333333"
[warn] Incomplete line in bandwidth file: "\n"
```
Turns out that line is 256 chars long (including the \n). The buffer in dirserv_read_measured_bandwidths() - dirserv.c:2263 - is slightly too short to hold that.
Please consider using a longer char line[] there.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13988Report bandwidth usage aggregated over a longer period2020-06-13T14:41:12ZNick MathewsonReport bandwidth usage aggregated over a longer periodNUM_SECS_BW_SUM_INTERVAL == 15 minutes seems pretty short; can we go up to 4 hours or 6 hours or so?
Note that while 0.2.2.x was still on the network we couldn't do this:
```
/** How large are the intervals for which we track and report...NUM_SECS_BW_SUM_INTERVAL == 15 minutes seems pretty short; can we go up to 4 hours or 6 hours or so?
Note that while 0.2.2.x was still on the network we couldn't do this:
```
/** How large are the intervals for which we track and report bandwidth use? */
/* XXXX Watch out! Before Tor 0.2.2.21-alpha, using any other value here would
* generate an unparseable state file. */
#define NUM_SECS_BW_SUM_INTERVAL (15*60)
```
But now, nobody should be downgrading to 0.2.2.x; this change should be approximately trivial.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13325Tor crash on OpenBSD-current since 2014-08-102020-06-13T14:39:19ZfredzupyTor crash on OpenBSD-current since 2014-08-10Tor is broken under OpenBSD-current since this patch, I think, <http://marc.info/?l=openbsd-cvs&m=140768179627976&w=2>).
The function prune_v2_cipher_list() in src/common/tortls.c now crash Tor (Segmentation fault). All Tor versions impa...Tor is broken under OpenBSD-current since this patch, I think, <http://marc.info/?l=openbsd-cvs&m=140768179627976&w=2>).
The function prune_v2_cipher_list() in src/common/tortls.c now crash Tor (Segmentation fault). All Tor versions impacted.
Commenting out the prune_v2_cipher_list() seems to be enough as a workaround.
Here is a gdb backtrace with tor-0.2.5.7-rc in debug mode:
Oct 02 14:41:12.000 [debug] tor_tls_debug_state_callback(): SSL 0x83b91000 is now in state before/accept initialization [type=16,val=1].
Oct 02 14:41:12.000 [debug] tor_tls_debug_state_callback(): SSL 0x83b91000 is now in state before/accept initialization [type=8193,val=1].
Oct 02 14:41:12.000 [debug] tor_tls_debug_state_callback(): SSL 0x83b91000 is now in state unknown state [type=8194,val=-1].
Oct 02 14:41:12.000 [debug] tor_tls_handshake(): After call, 0x82a59d80 was in state unknown state
Oct 02 14:41:12.000 [debug] connection_tls_continue_handshake(): wanted read
Oct 02 14:41:12.000 [debug] conn_read_callback(): socket 22 wants to read.
Oct 02 14:41:12.000 [debug] tor_tls_handshake(): About to call SSL_accept on 0x82a59d80 (unknown state)
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x1a8d578b in tor_tls_classify_client_ciphers (ssl=0x83b91000, peer_ciphers=0x85251200) at src/common/tortls.c:1489
#2 0x1a8d58ff in tor_tls_session_secret_cb (ssl=0x83b91000, secret=0x8a659608, secret_len=0x8a659604, peer_ciphers=0x85251200, cipher=0xcfbe0184, arg=0x0) at src/common/tortls.c:1683
#3 0x0b9e09ec in ssl3_get_client_hello (s=0x83b91000) at /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s3_srvr.c:1119
#4 0x0b9e176f in ssl3_accept (s=0x83b91000) at /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s3_srvr.c:346
#5 0x0b9f22fa in SSL_accept (s=0x83b91000) at /usr/src/lib/libssl/ssl/../../libssl/src/ssl/ssl_lib.c:922
#6 0x0b9d8836 in ssl23_get_client_hello (s=0x83b91000) at /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_srvr.c:573
#7 0x0b9d915c in ssl23_accept (s=0x83b91000) at /usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_srvr.c:232
#8 0x0b9f22fa in SSL_accept (s=0x83b91000) at /usr/src/lib/libssl/ssl/../../libssl/src/ssl/ssl_lib.c:922
#9 0x1a8d5d59 in tor_tls_handshake (tls=0x82a59d80) at src/common/tortls.c:2113
#10 0x1a865f10 in connection_tls_continue_handshake (conn=0x83b93000) at src/or/connection_or.c:1468
#11 0x1a857dee in connection_handle_read (conn=0x83b93000) at src/or/connection.c:3287
#12 0x1a7a842f in conn_read_callback (fd=22, event=2, _conn=0x83b93000) at src/or/main.c:736
#13 0x0bb9ca02 in event_base_loop (base=0x7e447000, flags=0) at /usr/src/lib/libevent/event.c:404
#14 0x1a7a3eab in do_main_loop () at src/or/main.c:2027
#15 0x1a7a55ca in tor_main (argc=3, argv=0xcfbe09c4) at src/or/main.c:3047
#16 0x1a7a1cdd in main (argc=536912672, argv=0x8696ee00) at src/or/tor_main.c:30
(gdb)Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13295tor-resolve asserts due to missing crypto initialization.2020-06-13T14:39:14ZYawning Angeltor-resolve asserts due to missing crypto initialization.From IRC, trivial to reproduce.
```
ypres :: Development/tor/build ‹master*› % ./src/tools/tor-resolve www.google.com localhost:9050
Sep 29 15:32:50.517 [err] tor_assertion_failed_(): Bug: ../src/ext/csiphash.c:156: siphash24g: Assertio...From IRC, trivial to reproduce.
```
ypres :: Development/tor/build ‹master*› % ./src/tools/tor-resolve www.google.com localhost:9050
Sep 29 15:32:50.517 [err] tor_assertion_failed_(): Bug: ../src/ext/csiphash.c:156: siphash24g: Assertion the_siphash_key_is_set failed; aborting.
Sep 29 15:32:50.517 [err] Bug: Assertion the_siphash_key_is_set failed in siphash24g at ../src/ext/csiphash.c:156. Stack trace:
Sep 29 15:32:50.517 [err] Bug: ./src/tools/tor-resolve(log_backtrace+0x41) [0x7f173d0e1fe1]
Sep 29 15:32:50.517 [err] Bug: ./src/tools/tor-resolve(tor_assertion_failed_+0x8c) [0x7f173d0d619c]
Sep 29 15:32:50.517 [err] Bug: ./src/tools/tor-resolve(siphash24g+0x5f) [0x7f173d0e1def]
Sep 29 15:32:50.517 [err] Bug: ./src/tools/tor-resolve(+0x235cc) [0x7f173d0df5cc]
Sep 29 15:32:50.518 [err] Bug: ./src/tools/tor-resolve(sandbox_getaddrinfo+0x75) [0x7f173d0e0e85]
Sep 29 15:32:50.518 [err] Bug: ./src/tools/tor-resolve(tor_addr_lookup+0x119) [0x7f173d0c88e9]
Sep 29 15:32:50.518 [err] Bug: ./src/tools/tor-resolve(tor_lookup_hostname+0x25) [0x7f173d0cd7e5]
Sep 29 15:32:50.518 [err] Bug: ./src/tools/tor-resolve(addr_port_lookup+0xb2) [0x7f173d0c9b52]
Sep 29 15:32:50.518 [err] Bug: ./src/tools/tor-resolve(main+0x182) [0x7f173d0c7012]
Sep 29 15:32:50.518 [err] Bug: /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f173b943040]
Sep 29 15:32:50.518 [err] Bug: ./src/tools/tor-resolve(+0xbb52) [0x7f173d0c7b52]
[1] 19923 abort (core dumped) ./src/tools/tor-resolve www.google.com localhost:9050
```
I reproduced it with master, but any version that uses the siphash backed HT implementation will have this problem. Calling `crypto_global_init()` and linking the appropriate libraries fixes the problem, naturally.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13214HS clients don't validate descriptor-id returned by HSDir2020-06-13T14:38:58ZJohn BrooksHS clients don't validate descriptor-id returned by HSDirThe rend descriptor cache for clients uses the permanent hostname as a key, instead of the descriptor-id (changed every 24 hours). When a descriptor is returned from a HSDir, the response is kept if the permanent hostname matches. The de...The rend descriptor cache for clients uses the permanent hostname as a key, instead of the descriptor-id (changed every 24 hours). When a descriptor is returned from a HSDir, the response is kept if the permanent hostname matches. The descriptor-id is not compared to the original request.
```
switch (rend_cache_store_v2_desc_as_client(body, conn->rend_data)) {
...
rend_client_desc_trynow(conn->rend_data->onion_address);
```
HS descriptors are currently valid for 3 days (#13207). A HSDir could fetch and serve a days-old descriptor for the same service, and that response will be used by clients.
There is no denial of service; the client will fetch from another directory after all introductions fail. The worst effect I can see is that a HSDir could briefly distract clients by serving a very old descriptor.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13124Lower severity of log: Pluggable transport proxy (%s) does not provide any ne...2020-06-13T14:38:33ZGeorge KadianakisLower severity of log: Pluggable transport proxy (%s) does not provide any needed transports and will not be launched.Apparently, TBB users who use PTs, get hit by:
```
log_notice(LD_GENERAL, "Pluggable transport proxy (%s) does not provide "
"any needed transports and will not be launched.", line);
```
since no one really uses al...Apparently, TBB users who use PTs, get hit by:
```
log_notice(LD_GENERAL, "Pluggable transport proxy (%s) does not provide "
"any needed transports and will not be launched.", line);
```
since no one really uses all the available PTs in the TBBs.
Roger suggested downgrading that log message to info or something. I think this makes sense, since it only hits TBB users and they don't learn any useful information from it. They also think it's an error and it confuses them.
Roger suggested tor-0.2.5 as the target release for this, since the TBB people want tbb-4.0 to include 0.2.5.x.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13096[patch] routerlist: NULL struct pointer dereferenced to take address of element2020-06-13T14:38:26Zteor[patch] routerlist: NULL struct pointer dereferenced to take address of elementIn routerlist.c line 4953, a struct pointer that is sometimes NULL is dereferenced by an assertion. The assertion then takes the address of one of the struct's element (routerlist.c 4953):
tor_assert(sd != &(r2->cache_info));
This is un...In routerlist.c line 4953, a struct pointer that is sometimes NULL is dereferenced by an assertion. The assertion then takes the address of one of the struct's element (routerlist.c 4953):
tor_assert(sd != &(r2->cache_info));
This is undefined behaviour in C, and could lead to the optimiser ignoring the check, or the program crashing.
To avoid dereferencing the potentially-NULL pointer, the assertion can be modified to check for NULL r2 first (if this is what is intended):
tor_assert(!r2 || sd != &(r2->cache_info));
The attached patch makes this change.
FYI - this error was discovered using a tor built with:
clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error -ftrapv
Version: tor 0.2.6.?-alpha git 54348201f7cce9c0c01e9d4835714a2fec55c67cTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13092Add cscope generated files to gitignore2020-06-13T14:38:26ZDavid Gouletdgoulet@torproject.orgAdd cscope generated files to gitignoreThe patch simply adds the cscope.* files to the .gitignore file. These are generated with "make cscope".The patch simply adds the cscope.* files to the .gitignore file. These are generated with "make cscope".Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13074“Pluggable transport will not be launched” notice makes it hard to read users...2020-06-13T14:38:21ZLunar“Pluggable transport will not be launched” notice makes it hard to read users' logsNow that pluggable transports are integrated by defaults in the Tor Browser, users' logs contain many times the _pluggable transport will not be launched_ notice:
```
Pluggable transport proxy (obfs2,obfs3 exec obfsproxy managed) does no...Now that pluggable transports are integrated by defaults in the Tor Browser, users' logs contain many times the _pluggable transport will not be launched_ notice:
```
Pluggable transport proxy (obfs2,obfs3 exec obfsproxy managed) does not provide any needed transports and will not be launched
```
When no pluggable transports are used, the notice appears 15 times before Tor bootstrap phase begins. Making the log harder to understand than it should.
Maybe the notice ought to be reversed? “Will start pluggable transport X as required”?Tor: 0.2.5.x-finalYawning AngelYawning Angel