Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:50:33Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29922util/time test failure on Jenkins2020-06-27T13:50:33ZAlexander Færøyahf@torproject.orgutil/time test failure on JenkinsOur 'util/time' test fails on our tor-ci-mingwcross-master-test builder with:
```
util/time: Mar 27 13:29:43.773 [warn] tor_gmtime_r(): Bug: gmtime(-1) failed with error Invalid argument: Rounding up to 1970 (on Tor 0.4.1.0-alpha-dev )
...Our 'util/time' test fails on our tor-ci-mingwcross-master-test builder with:
```
util/time: Mar 27 13:29:43.773 [warn] tor_gmtime_r(): Bug: gmtime(-1) failed with error Invalid argument: Rounding up to 1970 (on Tor 0.4.1.0-alpha-dev )
[time FAILED]
```
See: https://jenkins.torproject.org/job/tor-ci-mingwcross-master-test/ARCHITECTURE=amd64,SUITE=stretch/lastBuild/consoleTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29875Going from obfs4 to snowflake using the Tor Network Settings from the Torbutt...2021-02-25T15:32:26ZcypherpunksGoing from obfs4 to snowflake using the Tor Network Settings from the Torbutton doesn't workGoing from obfs4 to snowflake using the Tor Network Settings from the Torbutton doesn't work, i.e. nothing happens and no website can load, if I restart the browser then snowflake works perfectlyGoing from obfs4 to snowflake using the Tor Network Settings from the Torbutton doesn't work, i.e. nothing happens and no website can load, if I restart the browser then snowflake works perfectlyTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29824CID 1444119 resource leak in BUG case in consdiff.c2020-06-27T13:50:37ZTaylor YuCID 1444119 resource leak in BUG case in consdiff.c```
*** CID 1444119: Resource leaks (RESOURCE_LEAK)
/src/feature/dircommon/consdiff.c: 1392 in consensus_diff_apply()
1386 int r1;
1387 char *result = NULL;
1388 memarea_t *area = memarea_new();
1389
1390 r...```
*** CID 1444119: Resource leaks (RESOURCE_LEAK)
/src/feature/dircommon/consdiff.c: 1392 in consensus_diff_apply()
1386 int r1;
1387 char *result = NULL;
1388 memarea_t *area = memarea_new();
1389
1390 r1 = consensus_compute_digest_as_signed(consensus, consensus_len, &d1);
1391 if (BUG(r1 < 0))
>>> CID 1444119: Resource leaks (RESOURCE_LEAK)
>>> Variable "area" going out of scope leaks the storage it points to.
1392 return NULL; // LCOV_EXCL_LINE
1393
1394 lines1 = smartlist_new();
1395 lines2 = smartlist_new();
1396 if (consensus_split_lines(lines1, consensus, consensus_len, area) < 0)
1397 goto done;
```
This looks to be a leak if there is a `BUG()` condition, and the line is already marked `LCOV_EXCL_LINE`. Should we mark this as ignored or something in Coverity, or do we want to put cleanup code under that `BUG()` condition?Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29819Seccomp: sandbox crash on rt_sigaction with libseccomp 0.2.42020-07-14T22:24:27ZtoralfSeccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4With Sandbox=1 I do get with the new stable Vanilla Linux kernel
```
============================================================ T= 1553016509
(Sandbox) Caught a bad syscall attempt (syscall rt_sigaction)
/usr/bin/tor(+0x1ce5aa)[0x5636a...With Sandbox=1 I do get with the new stable Vanilla Linux kernel
```
============================================================ T= 1553016509
(Sandbox) Caught a bad syscall attempt (syscall rt_sigaction)
/usr/bin/tor(+0x1ce5aa)[0x5636adfa15aa]
/lib64/libpthread.so.0(+0x14125)[0x7f0d99074125]
/lib64/libpthread.so.0(+0x14125)[0x7f0d99074125]
/usr/lib64/libevent-2.1.so.6(evsig_set_handler_+0xeb)[0x7f0d99f4df8b]
/usr/lib64/libevent-2.1.so.6(+0x2c0b6)[0x7f0d99f4e0b6]
/usr/lib64/libevent-2.1.so.6(evmap_signal_add_+0xb5)[0x7f0d99f46b55]
/usr/lib64/libevent-2.1.so.6(event_add_nolock_+0x74e)[0x7f0d99f421ce]
/usr/lib64/libevent-2.1.so.6(event_add+0x3a)[0x7f0d99f423fa]
/usr/bin/tor(handle_signals+0xa7)[0x5636ade2a0c7]
/usr/bin/tor(run_tor_main_loop+0x1a)[0x5636ade2ac8a]
/usr/bin/tor(tor_run_main+0x1045)[0x5636ade2bea5]
/usr/bin/tor(tor_main+0x43)[0x5636ade293e3]
/usr/bin/tor(main+0x19)[0x5636ade28f99]
/lib64/libc.so.6(__libc_start_main+0xe7)[0x7f0d98cb9ae7]
/usr/bin/tor(_start+0x2a)[0x5636ade28fea]
```
An strace narrows it down to
```
write(2, "(Sandbox) Caught a bad syscall a"..., 48(Sandbox) Caught a bad syscall attempt (syscall ) = 48
```Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29702Stop using configs from the local tor install when we launch tor for tests2021-09-16T14:24:10ZteorStop using configs from the local tor install when we launch tor for testsWe should stop using paths in /usr when we're launching tor for build tests.
We don't get full logs for all the tor processes we launch, but these scripts launch tor, so they're probably affected:
* test_rebind.sh
* test_key_expiration....We should stop using paths in /usr when we're launching tor for build tests.
We don't get full logs for all the tor processes we launch, but these scripts launch tor, so they're probably affected:
* test_rebind.sh
* test_key_expiration.sh
* test_keygen.sh
* test_zero_length_keys.sh
test-network.sh is also affected, but we'll deal with that in chutney in legacy/trac#29701.
For example, on my machine, test_rebind.sh does:
```
2019-03-05 11:00:11.573 Tor logged: "Mar 05 11:00:11.571 [notice] Configuration file "/usr/local/etc/tor/torrc" not present, using reasonable defaults.", waiting for "Opened Control listener on"
2019-03-05 11:00:11.596 Tor logged: "Mar 05 11:00:11.591 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.", waiting for "Opened Socks listener"
2019-03-05 11:00:11.899 Tor logged: "Mar 05 11:00:11.899 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.", waiting for "Opened Socks listener"
```Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/29670Could not create SOCKS args string2020-06-27T13:50:43ZcypherpunksCould not create SOCKS args stringSet a SOCKS5 authenticated proxy listening on 127.0.0.1 using the browser launching wizard. tbb 8.0.6 (64bits) on Debian
```
3/6/19, 21:32:17.612 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connection...Set a SOCKS5 authenticated proxy listening on 127.0.0.1 using the browser launching wizard. tbb 8.0.6 (64bits) on Debian
```
3/6/19, 21:32:17.612 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
3/6/19, 21:32:17.613 [NOTICE] Opening Socks listener on 127.0.0.1:9150
3/6/19, 21:32:17.613 [NOTICE] Opened Socks listener on 127.0.0.1:9150
3/6/19, 21:32:17.613 [NOTICE] Bootstrapped 5%: Connecting to directory server
3/6/19, 21:32:17.614 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server
3/6/19, 21:32:17.614 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:17.614 [WARN] Proxy Client: unable to connect to 69.164.220.107:443
3/6/19, 21:32:18.598 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:18.599 [WARN] Proxy Client: unable to connect to 51.75.144.67:443
3/6/19, 21:32:19.602 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:19.603 [WARN] Proxy Client: unable to connect to 37.218.242.26:443
3/6/19, 21:32:20.606 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:20.607 [WARN] Proxy Client: unable to connect to 81.7.14.253:443
3/6/19, 21:32:21.610 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:21.611 [WARN] Proxy Client: unable to connect to 51.15.77.244:443
3/6/19, 21:32:23.619 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:23.620 [WARN] Proxy Client: unable to connect to 5.39.60.243:443
3/6/19, 21:32:23.620 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:23.621 [WARN] Proxy Client: unable to connect to 171.25.193.9:80
3/6/19, 21:32:28.638 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:28.638 [WARN] Proxy Client: unable to connect to 77.243.191.102:443
3/6/19, 21:32:29.642 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:29.642 [WARN] Proxy Client: unable to connect to 131.188.40.189:443
3/6/19, 21:32:37.674 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:37.674 [WARN] Proxy Client: unable to connect to 81.7.11.186:443
3/6/19, 21:32:41.686 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:41.686 [WARN] Proxy Client: unable to connect to 193.23.244.244:443
3/6/19, 21:32:50.722 [WARN] Could not create SOCKS args string.
3/6/19, 21:32:50.722 [WARN] Proxy Client: unable to connect to 86.59.21.38:443
3/6/19, 21:33:02.770 [WARN] Could not create SOCKS args string.
3/6/19, 21:33:02.770 [WARN] Proxy Client: unable to connect to 212.47.231.164:443
3/6/19, 21:33:04.778 [WARN] Could not create SOCKS args string.
3/6/19, 21:33:04.778 [WARN] Proxy Client: unable to connect to 194.109.206.212:443
3/6/19, 21:33:34.894 [WARN] Could not create SOCKS args string.
3/6/19, 21:33:34.894 [WARN] Proxy Client: unable to connect to 204.13.164.118:443
3/6/19, 21:33:45.941 [WARN] Could not create SOCKS args string.
3/6/19, 21:33:45.942 [WARN] Proxy Client: unable to connect to 66.206.0.138:443
3/6/19, 21:34:21.740 [WARN] Could not create SOCKS args string.
3/6/19, 21:34:21.740 [WARN] Proxy Client: unable to connect to 154.35.175.225:443
3/6/19, 21:34:34.127 [WARN] Could not create SOCKS args string.
3/6/19, 21:34:34.128 [WARN] Proxy Client: unable to connect to 199.58.81.140:443
3/6/19, 21:34:40.150 [WARN] Could not create SOCKS args string.
3/6/19, 21:34:40.150 [WARN] Proxy Client: unable to connect to 198.50.191.95:443
3/6/19, 21:34:40.658 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
3/6/19, 21:34:40.658 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
```Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29617OOM manger wipes entire DNS cache2020-06-27T13:50:46ZpullsOOM manger wipes entire DNS cacheIn relay.c, function cell_queues_check_size, the OOM manager attempts to clear one tenth of MaxMemInQueues bytes from the DNS cache by calling dns_cache_handle_oom. The function dns_cache_handle_oom, in dns.c, runs in a loop removing cac...In relay.c, function cell_queues_check_size, the OOM manager attempts to clear one tenth of MaxMemInQueues bytes from the DNS cache by calling dns_cache_handle_oom. The function dns_cache_handle_oom, in dns.c, runs in a loop removing cached entries that are now+n*time_inc old, until at least the requested number of bytes have been freed. The first iteration of the loop has n=0, and likely will not remove enough bytes. The second iteration is way too aggressive, because:
```
time_inc += 3600; /* Increase time_inc by 1 hour. */
```
This is guaranteed to wipe the entire DNS cache, because in dns_clip_ttl the maximum time to cache is MAX_DNS_TTL_AT_EXIT, which is set in dns.h to:
```
/** Lowest value for DNS ttl that a server will give. */
#define MIN_DNS_TTL_AT_EXIT (5*60)
/** Highest value for DNS ttl that a server will give. */
#define MAX_DNS_TTL_AT_EXIT (60*60)
```
One possible and reasonable fix would be to instead increment time_inc by MIN_DNS_TTL_AT_EXIT.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29612Update the documentation for ExitRelay2021-07-22T16:19:43ZteorUpdate the documentation for ExitRelayIn legacy/trac#21530 in 0.3.5, we changed the default of ExitRelay: relays used to be exits by default, but now they are not.
But we forgot to update the documentation.In legacy/trac#21530 in 0.3.5, we changed the default of ExitRelay: relays used to be exits by default, but now they are not.
But we forgot to update the documentation.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29601Drop redundant jobs on Appveyor to speed up builds2020-06-27T13:50:48ZteorDrop redundant jobs on Appveyor to speed up buildsOur Appveyor builds are really slow. We can still get decent coverage if we drop some redundant jobs.
The remaining builds will be:
* 64-bit Windows Server 2016
* 32-bit Windows Server 2012 R2
We can also set fast_finish, so the first ...Our Appveyor builds are really slow. We can still get decent coverage if we drop some redundant jobs.
The remaining builds will be:
* 64-bit Windows Server 2016
* 32-bit Windows Server 2012 R2
We can also set fast_finish, so the first failed job terminates the build immediately.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29530Some address/get_if_addrs* tests fail when the network is unreachable2020-06-27T13:50:52ZteorSome address/get_if_addrs* tests fail when the network is unreachableI see these failures when my network connection is off:
```
address/get_if_addrs_list_internal: Feb 19 21:28:39.823 [err] connect() failed:
Network is unreachable
[get_if_addrs_list_internal FAILED]
address/get_if_addrs_list_no_inter...I see these failures when my network connection is off:
```
address/get_if_addrs_list_internal: Feb 19 21:28:39.823 [err] connect() failed:
Network is unreachable
[get_if_addrs_list_internal FAILED]
address/get_if_addrs_list_no_internal: Feb 19 21:28:39.825 [err] connect() failed: Network is unreachable
[get_if_addrs_list_no_internal FAILED]
address/get_if_addrs6_list_internal: OK
address/get_if_addrs6_list_no_internal: [forking] OK
address/get_if_addrs_internal_fail: OK
address/get_if_addrs_no_internal_fail: OK
address/get_if_addrs: Feb 19 21:28:39.881 [err] connect() failed: Network is unreachable
[get_if_addrs FAILED]
```
The quick fix is to downgrade them to warnings.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29435coverage script broken by library refactoring2020-06-27T13:50:56ZNick Mathewsoncoverage script broken by library refactoringThe fix is easy here; I'll write a patch.The fix is easy here; I'll write a patch.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29241NSS SSL_ExportKeyingMaterial failing2020-06-27T13:51:00ZMatthew FinkelNSS SSL_ExportKeyingMaterial failingPossibly similar/related to legacy/trac#28616/legacy/trac#28973.
```
[warn] connection_or_compute_authenticate_cell_body(): Bug: TLS key export failed for unknown reason. (on Tor 0.4.0.1-alpha )
[warn] Couldn't send authenticate cell
[n...Possibly similar/related to legacy/trac#28616/legacy/trac#28973.
```
[warn] connection_or_compute_authenticate_cell_body(): Bug: TLS key export failed for unknown reason. (on Tor 0.4.0.1-alpha )
[warn] Couldn't send authenticate cell
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
[warn] connection_or_compute_authenticate_cell_body(): Bug: TLS key export failed for unknown reason. (on Tor 0.4.0.1-alpha )
[warn] Couldn't send authenticate cell
[warn] connection_or_compute_authenticate_cell_body(): Bug: TLS key export failed for unknown reason. (on Tor 0.4.0.1-alpha )
[warn] Couldn't send authenticate cell
[warn] connection_or_compute_authenticate_cell_body(): Bug: TLS key export failed for unknown reason. (on Tor 0.4.0.1-alpha )
[warn] Couldn't send authenticate cell
[warn] connection_or_compute_authenticate_cell_body(): Bug: TLS key export failed for unknown reason. (on Tor 0.4.0.1-alpha )
[warn] Couldn't send authenticate cell
[notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
[notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
[notice] Bootstrapped 90% (ap_handshake_done): Handshake fininshed with a relay to build circuits
[notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
[warn] connection_or_compute_authenticate_cell_body(): Bug: TLS key export failed for unknown reason. (on Tor 0.4.0.1-alpha )
[warn] Couldn't send authenticate cell
[notice] Bootstrapped 100% (done): Done
[warn] connection_or_compute_authenticate_cell_body(): Bug: TLS key export failed for unknown reason. (on Tor 0.4.0.1-alpha )
[warn] Couldn't send authenticate cell
[warn] connection_or_compute_authenticate_cell_body(): Bug: TLS key export failed for unknown reason. (on Tor 0.4.0.1-alpha )
[warn] Couldn't send authenticate cell
[warn] connection_or_compute_authenticate_cell_body(): Bug: TLS key export failed for unknown reason. (on Tor 0.4.0.1-alpha )
```
Reported by Alex on tor-relays@ - https://lists.torproject.org/pipermail/tor-relays/2019-January/016890.htmlTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29175Tor 0.3.5.x mishandles empty socks5 auth2020-06-27T13:51:05ZRoger DingledineTor 0.3.5.x mishandles empty socks5 authThere is a regression in Tor 0.3.5.x with handling socks5 handshakes that offer username/password auth but then present empty username and password.
It came in during commit 9068ac3c (which went into 0.3.5.1-alpha).
The symptom is that...There is a regression in Tor 0.3.5.x with handling socks5 handshakes that offer username/password auth but then present empty username and password.
It came in during commit 9068ac3c (which went into 0.3.5.1-alpha).
The symptom is that when you do your socks5 handshake with an empty username and password (e.g. like pidgin does it), you get log lines like
```
Jan 24 19:40:17.000 [warn] Fetching socks handshake failed. Closing.
Jan 24 19:40:17.000 [warn] socks5: parsing failed - invalid user/pass authentication message.
```
Bug reported by a person on #tor, and also separately by legacy/trac#29050.
I asked Josh Glazebrook, the author of the socks library in legacy/trac#29050, for some actual traces of correct behavior / incorrect behavior, and he sent:
```
socks v2.2.3
tor v0.3.5.7
client announces it only supports noauth (00)
server chooses noauth (00)
send <Buffer 05 01 00> [00 = noauth]
recv <Buffer 05 00> [server chose noauth]
send <Buffer 05 01 00 03 09 69 70 69 6e 66 6f 2e 69 6f 00 50> [connect command - ipinfo.io]
recv <Buffer 05 00 00 01 00> [success]
socks v2.2.2
tor v0.3.5.7
client announces it supports noauth (00) and userpass (02)
server chooses userpass (02)
connection is unsuccessful - server returns general socks server failure, tor logs indicate invalid user/pass.
Jan 24 14:47:15.000 [warn] Fetching socks handshake failed. Closing.
Jan 24 14:47:56.000 [warn] socks5: parsing failed - invalid user/pass authentication message.
send <Buffer 05 02 00 02> [00 = noauth, 02 = userpass]
recv <Buffer 05 02> [server chose userpass]
send <Buffer 01 00 00> [00 = zero length username, 00 = zero length password]
recv <Buffer 01 00> [00 = server indicates auth success]
send <Buffer 05 01 00 03 09 69 70 69 6e 66 6f 2e 69 6f 00 50> [connect command - ipinfo.io]
recv <Buffer 05 01 00 01 00> [01- general SOCKS server failure] (in tor's log output it's saying auth is invalid at this point)
socks v.2.2.2
tor via torbrowser 8.0.4 (unsure of which tor version, but likely older than 0.3.5.7)
client announces it supports noauth (00) and userpass (02)
server chooses userpass (02)
connection is successful
send <Buffer 05 02 00 02> [00 = noauth, 02 = userpass]
recv <Buffer 05 02> [server chose userpass]
send <Buffer 01 00 00> [00 = zero length username, 00 = zero length password]
recv <Buffer 01 00> [00 = server indicates auth success]
send <Buffer 05 01 00 03 09 69 70 69 6e 66 6f 2e 69 6f 00 50> [connect command - ipinfo.io]
recv <Buffer 05 00 00 01 00> [00 = success]
```
Josh further gives us this hint:
```
It appears there is indeed something that changed between older versions of
Tor and newer versions. Looking at the actual data being exchanged, it's
exactly the same.
The only odd thing is tor v0.3.5.7 is indicating in the auth reply that the
authentication was a success, and only when the connect command is sent,
it's returning a "general socks server failure" code, but in the actual tor
log it's logging invalid user/pass.
```
I went spelunking and found this code newly in 0.3.5.x:
```
if (usernamelen && username) {
tor_free(req->username);
req->username = tor_memdup_nulterm(username, usernamelen);
req->usernamelen = usernamelen;
req->got_auth = 1;
}
if (passwordlen && password) {
tor_free(req->password);
req->password = tor_memdup_nulterm(password, passwordlen);
req->passwordlen = passwordlen;
req->got_auth = 1;
}
```
Compare to the code in 0.3.4.x:
```
if (usernamelen) {
req->username = tor_memdup(data+2u, usernamelen);
req->usernamelen = usernamelen;
}
if (passlen) {
req->password = tor_memdup(data+3u+usernamelen, passlen);
req->passwordlen = passlen;
}
*drain_out = 2u + usernamelen + 1u + passlen;
req->got_auth = 1;
```
So in 0.3.4.x when we got a type 0x02 handshake but empty username and empty password, we would still set got_auth to 1. In 0.3.5.x when that happens, we leave got_auth at 0.
The result is that the socks5 handshake itself still goes identically, but when we get the empty username and password, we **don't record that we received it**, even though we send back a "handshake was successful" response. And then when application data shows up after that, we try to treat it as a socks5 username and password, because we're still waiting for one. That's where things go bad.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/29145Fix a compiler warning on OpenBSD in test-memwipe.c2020-06-27T13:51:06ZTracFix a compiler warning on OpenBSD in test-memwipe.cIn test-memwipe.c, `malloc_options` needs to be declared extern:
```
src/test/test-memwipe.c:50:13: warning: no previous extern declaration for non-static variable 'malloc_options' [-Wmissing-variable-declarations]
const char *malloc_op...In test-memwipe.c, `malloc_options` needs to be declared extern:
```
src/test/test-memwipe.c:50:13: warning: no previous extern declaration for non-static variable 'malloc_options' [-Wmissing-variable-declarations]
const char *malloc_options="sufjj";
```
(`malloc_options` is only used on OpenBSD)
PR to follow.
**Trac**:
**Username**: kjakTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29144Log the correct "auto" port number for listening sockets2020-06-27T13:51:06ZTracLog the correct "auto" port number for listening socketsWhen `auto` is used for the port number for a listening socket, the message that gets logged after opening the socket incorrectly says port 0 instead of the actual port being used.
A contrived config like this
```
ControlPort auto
Sock...When `auto` is used for the port number for a listening socket, the message that gets logged after opening the socket incorrectly says port 0 instead of the actual port being used.
A contrived config like this
```
ControlPort auto
SocksPort 127.0.0.1:auto
ORPort 127.0.0.1:auto
ORPort [::1]:auto
```
gives log messages like this
Jan 21 12:38:05.741 [notice] Opening Socks listener on 127.0.0.1:0
Jan 21 12:38:05.741 [notice] Socks listener listening on port 22840.
**Jan 21 12:38:05.741 [notice] Opened Socks listener on 127.0.0.1:0**
Jan 21 12:38:05.741 [notice] Opening Control listener on 127.0.0.1:0
Jan 21 12:38:05.741 [notice] Control listener listening on port 14414.
**Jan 21 12:38:05.741 [notice] Opened Control listener on 127.0.0.1:0**
Jan 21 12:38:05.741 [notice] Opening OR listener on 127.0.0.1:0
Jan 21 12:38:05.741 [notice] OR listener listening on port 19719.
**Jan 21 12:38:05.741 [notice] Opened OR listener on 127.0.0.1:0**
Jan 21 12:38:05.741 [notice] Opening OR listener on [::1]:0
Jan 21 12:38:05.742 [notice] OR listener listening on port 4298.
**Jan 21 12:38:05.742 [notice] Opened OR listener on [::1]:0**
An upcoming PR will fix this so that the log messages will have the actual port numbers like this
Jan 21 12:38:57.709 [notice] Opening Socks listener on 127.0.0.1:0
Jan 21 12:38:57.709 [notice] Socks listener listening on port 5236.
**Jan 21 12:38:57.709 [notice] Opened Socks listener on 127.0.0.1:5236**
Jan 21 12:38:57.709 [notice] Opening Control listener on 127.0.0.1:0
Jan 21 12:38:57.709 [notice] Control listener listening on port 14584.
**Jan 21 12:38:57.709 [notice] Opened Control listener on 127.0.0.1:14584**
Jan 21 12:38:57.709 [notice] Opening OR listener on 127.0.0.1:0
Jan 21 12:38:57.709 [notice] OR listener listening on port 15220.
**Jan 21 12:38:57.709 [notice] Opened OR listener on 127.0.0.1:15220**
Jan 21 12:38:57.709 [notice] Opening OR listener on [::1]:0
Jan 21 12:38:57.709 [notice] OR listener listening on port 36901.
**Jan 21 12:38:57.709 [notice] Opened OR listener on [::1]:36901**
This was introduced by commit 27c868eff19dbcc208f6db66ec3e2de2104fa754 and occurs in 0.3.5.1-alpha.
**Trac**:
**Username**: kjakTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29135Failing to connect to a v3 onion service with client auth produces really lon...2021-06-23T17:26:03ZpastlyFailing to connect to a v3 onion service with client auth produces really long lines in logIMO Tor shouldn't log the entire descriptor a level warn.
```
Jan 19 16:22:54.692 [warn] Client authorization for requested onion address is invalid. Can't decrypt the descriptor.
Jan 19 16:22:54.692 [warn] Failed to parse received desc...IMO Tor shouldn't log the entire descriptor a level warn.
```
Jan 19 16:22:54.692 [warn] Client authorization for requested onion address is invalid. Can't decrypt the descriptor.
Jan 19 16:22:54.692 [warn] Failed to parse received descriptor "hs-descriptor 3\ndescriptor-lifetime 180\ndescriptor-signing-key-cert\n-----BEGIN ED25519 CERT-----\nAQgABo/UAYFloHvVvnlNECHb5xleCJR [... it keeps going for about 4000 more characters ...]
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29042Error loading private key after 0.3.5.7 upgrade2020-06-27T13:51:13ZTracError loading private key after 0.3.5.7 upgradeHi,
I just upgraded my tor relay from 0.3.4.9 to 0.3.5.7 via the official debian repository. Now my relay is unable to start up:
Jan 10 11:24:48.000 [err] Error loading private key.
Jan 10 11:24:48.000 [err] Error initializing keys; ex...Hi,
I just upgraded my tor relay from 0.3.4.9 to 0.3.5.7 via the official debian repository. Now my relay is unable to start up:
Jan 10 11:24:48.000 [err] Error loading private key.
Jan 10 11:24:48.000 [err] Error initializing keys; exiting
What can I do to fix it?
root@DietPi:/var/lib/tor/keys# ls -lah
total 44K
drwx--S--- 2 tor tor 4.0K Jan 5 18:55 .
drwx--S--- 5 tor tor 4.0K Jan 10 11:24 ..
-rw-r--r-- 1 tor tor 64 Dec 13 2015 ed25519_master_id_public_key
-rw-r--r-- 1 tor tor 96 Dec 13 2015 ed25519_master_id_secret_key
-rw------- 1 tor tor 172 Dec 18 23:00 ed25519_signing_cert
-rw------- 1 tor tor 96 Dec 18 23:00 ed25519_signing_secret_key
-rw-r--r-- 1 tor tor 902 Nov 6 2013 secret_id_key
-rw------- 1 tor tor 887 Jan 5 18:55 secret_onion_key
-rw------- 1 tor tor 96 Jan 5 18:55 secret_onion_key_ntor
-rw------- 1 tor tor 96 Dec 8 18:07 secret_onion_key_ntor.old
-rw------- 1 tor tor 887 Dec 8 18:07 secret_onion_key.old
**Trac**:
**Username**: anongTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29040Tor crashes if ClientOnionAuthDir contains more than one private key for a hi...2021-06-23T17:26:03ZTracTor crashes if ClientOnionAuthDir contains more than one private key for a hidden serviceOS: Arch Linux,
Minimum torrc to reproduce problem:
```
ClientOnionAuthDir /var/lib/tor/auth
```
In /var/lib/tor/auth place a file, for example "key1.auth_private" with:
```
squlj76moawedtuiixydwlzj65323e6k232bpogd4xrrsz4bgcunyqad:des...OS: Arch Linux,
Minimum torrc to reproduce problem:
```
ClientOnionAuthDir /var/lib/tor/auth
```
In /var/lib/tor/auth place a file, for example "key1.auth_private" with:
```
squlj76moawedtuiixydwlzj65323e6k232bpogd4xrrsz4bgcunyqad:descriptor:x25519:XX5M5YQVTGCXPS3E6G6AGOUZYFISOLMSXLD2E3BTL22DUQZLHK4Q
```
then do
```
# cp /var/lib/tor/auth/key1.auth_private /var/lib/tor/auth/key2.auth_private
# tor -f /etc/tor/torrc
```
This yields the traceback:
```
Jan 10 03:57:29.597 [notice] Tor 0.3.5.7 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1a, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.7.
Jan 10 03:57:29.598 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jan 10 03:57:29.598 [notice] Read configuration file "/etc/tor/torrc".
Jan 10 03:57:29.612 [err] tor_assertion_failed_(): Bug: src/app/config/config.c:890: get_options_mutable: Assertion global_options failed; aborting. (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: Assertion global_options failed in get_options_mutable at src/app/config/config.c:890. Stack trace: (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(log_backtrace_impl+0x48) [0x571747260a18] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(tor_assertion_failed_+0x97) [0x57174725bee7] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(get_options_mutable+0x60) [0x5717471dc1d0] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(safe_str_client+0x22) [0x5717471dc552] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(hs_config_client_authorization+0x5a0) [0x571747168e10] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(hs_config_client_auth_all+0x30) [0x5717471fa7f0] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(+0x1798ab) [0x5717471e38ab] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(options_init_from_string+0x364) [0x5717471e7d34] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(options_init_from_torrc+0x376) [0x5717471e82f6] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(tor_init+0x32a) [0x5717470bd7ba] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(tor_run_main+0xcd) [0x5717470be54d] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(tor_main+0x3b) [0x5717470bc62b] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(main+0x1a) [0x5717470bc1ba] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: /usr/lib/libc.so.6(__libc_start_main+0xf3) [0x74f0206a9223] (on Tor 0.3.5.7 )
Jan 10 03:57:29.614 [err] Bug: tor(_start+0x2e) [0x5717470bc21e] (on Tor 0.3.5.7 )
```
**Trac**:
**Username**: demfloroTor: 0.3.5.x-finalhaxxpophaxxpophttps://gitlab.torproject.org/tpo/core/tor/-/issues/29034circuit: Cleanup an HS circuit when it is being re-purposed2020-06-27T13:51:13ZDavid Gouletdgoulet@torproject.orgcircuit: Cleanup an HS circuit when it is being re-purposedMike found out that when an IP/RP circuit fails to build in the right amount of time (for instance through `circuit_expire_building()`), it is re-purposed to become a measurement circuit.
The issue is that those HS circuits are set in t...Mike found out that when an IP/RP circuit fails to build in the right amount of time (for instance through `circuit_expire_building()`), it is re-purposed to become a measurement circuit.
The issue is that those HS circuits are set in the HS circuitmap and have an `hs_ident` or `rend_data` set to them that should really not linger in the circuit object if the circuit is not an HS one anymore.
Offenders: `circuit_build_times_mark_circ_as_measurement_only()` and `pathbias_send_usable_probe()`.
Solution:
`circuit_change_purpose()` is probably the right place to make a callback within the HS subsystem specific to cleaning up a circuit for a purpose change. I think we need a new function that specifically does that and not use `hs_circ_cleanup()` since it won't remove the ident.
Lingering circuits in the HS circuitmap is bad and this bug could probably explain some of the issues we had with clients unable to establish connections because the IP auth key wouldn't match the one in the circuit ident.
I strongly believe this should be backported up to 0.3.5 at the very least.Tor: 0.3.5.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29026OpenSSL will not compile without engine support2020-06-27T13:51:14ZTracOpenSSL will not compile without engine supportTor currently disables its engine support for Android only. This breaks compilation on other platforms that lack engine support.
This patch changes the check to check for OPENSSL_NO_ENGINE, which should work everywhere.
**Trac**:
**U...Tor currently disables its engine support for Android only. This breaks compilation on other platforms that lack engine support.
This patch changes the check to check for OPENSSL_NO_ENGINE, which should work everywhere.
**Trac**:
**Username**: MangixTor: 0.3.5.x-final