Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:51:06Zhttps://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/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/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/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/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/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/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/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/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/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/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/30011Kill test-stem if takes more than 9.5 minutes2020-06-27T13:50:30ZteorKill test-stem if takes more than 9.5 minutesLet's kill test-stem if it times out.Let's kill test-stem if it times out.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30117Support stem's backtrace signals in Travis2020-06-27T13:50:25ZteorSupport stem's backtrace signals in TravisIn legacy/trac#29437, we're trying to track down a stem hang in our CI.
In legacy/trac#30012, I added backtrace support to stem.
But we need that backtrace support in our CI to see why stem is hanging.In legacy/trac#29437, we're trying to track down a stem hang in our CI.
In legacy/trac#30012, I added backtrace support to stem.
But we need that backtrace support in our CI to see why stem is hanging.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30148Fix infrequent, unlikely memory leak on failure to create keys directory2020-06-27T13:50:24ZNick MathewsonFix infrequent, unlikely memory leak on failure to create keys directoryIn load_ed_keys(), if we can't create the key directory, we leak some memory.In load_ed_keys(), if we can't create the key directory, we leak some memory.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30189ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.2020-06-27T13:50:22ZNick MathewsonALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.Found while reviewing legacy/trac#30179:
We don't include stdlib.h in util_bugs.h, which is sometimes a problem, since the macros declared there can call abort().
This problem is particularly bad for the nonfatal assertions, since they...Found while reviewing legacy/trac#30179:
We don't include stdlib.h in util_bugs.h, which is sometimes a problem, since the macros declared there can call abort().
This problem is particularly bad for the nonfatal assertions, since they don't call abort() unless ALL_BUGS_ARE_FATAL is defined, which it only rarely is.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30190Do not warn about compatible OpenSSL upgrades2020-06-27T13:50:22ZteorDo not warn about compatible OpenSSL upgradesFrom https://github.com/torproject/tor/pull/951
When releasing OpenSSL patch-level maintenance updates,
we do not want to rebuild binaries using it.
And since they guarantee ABI stability, we do not have to.
Without this patch, warning...From https://github.com/torproject/tor/pull/951
When releasing OpenSSL patch-level maintenance updates,
we do not want to rebuild binaries using it.
And since they guarantee ABI stability, we do not have to.
Without this patch, warning messages were produced
that confused users:
https://bugzilla.opensuse.org/show_bug.cgi?id=1129411Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30234Get a stacktrace from tor processes launched by stem2020-06-27T13:50:21ZteorGet a stacktrace from tor processes launched by stemWe need to show the stem tor log at the end of the build.
We might also need to propagate the USR1 and abort signals to tor.We need to show the stem tor log at the end of the build.
We might also need to propagate the USR1 and abort signals to tor.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30316Vote's 'bandwidth-file-headers' is in wrong order2020-06-27T13:50:17ZDamian JohnsonVote's 'bandwidth-file-headers' is in wrong orderHi network team. Moria1's present vote places its "bandwidth-file-headers" in the wrong location.
Tor's dir-spec says: "**Status documents contain a preamble, an authority section, a list of router status entries, and one or more footer...Hi network team. Moria1's present vote places its "bandwidth-file-headers" in the wrong location.
Tor's dir-spec says: "**Status documents contain a preamble, an authority section, a list of router status entries, and one or more footer signature, in that order.**"
The trouble is that our bandwidth-file-headers field is specified as being part of the preamble, whereas moria1 places it **after** its authority section. Header fields appear in the following order...
* flag-thresholds (preamble)
* params (preamble)
* dir-source (authority section)
* contact (authority section)
* shared-rand-participate (authority section)
* shared-rand-commit (authority section, multiple)
* shared-rand-previous-value (authority section)
* shared-rand-current-value (authority section)
* **bandwidth-file-headers (preamble)**
* dir-key-certificate-version (key certificate)
* ... etc...
As a result Stem does not parse this field: legacy/trac#30282Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30452List which compile-time modules are enabled2020-06-27T13:50:14ZNick MathewsonList which compile-time modules are enabledWe should have a way to find out which compile-time modules Tor was built with.We should have a way to find out which compile-time modules Tor was built with.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30475hs_service.c: compile-time warning with GCC 9.1.12020-06-27T13:50:13ZNick Mathewsonhs_service.c: compile-time warning with GCC 9.1.1I tried building with GCC 9.1.1 for the first time, and got various warnings.
```
make[1]: Entering directory '/home/nickm/src/tor-035'
CC src/feature/hs/hs_service.o
In file included from ./src/lib/crypt_ops/crypto_rsa.h:21,
...I tried building with GCC 9.1.1 for the first time, and got various warnings.
```
make[1]: Entering directory '/home/nickm/src/tor-035'
CC src/feature/hs/hs_service.o
In file included from ./src/lib/crypt_ops/crypto_rsa.h:21,
from ./src/core/or/or.h:32,
from src/feature/hs/hs_service.c:11:
In function ‘load_client_keys’,
inlined from ‘load_service_keys’ at src/feature/hs/hs_service.c:1090:7,
inlined from ‘hs_service_load_all_keys’ at src/feature/hs/hs_service.c:4010:9:
./src/lib/log/log.h:244:3: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
244 | log_fn_(LOG_WARN, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/feature/hs/hs_service.c:1267:7: note: in expansion of macro ‘log_warn’
1267 | log_warn(LD_REND, "Client authorization file %s can't be read. "
| ^~~~~~~~
src/feature/hs/hs_service.c: In function ‘hs_service_load_all_keys’:
src/feature/hs/hs_service.c:1267:52: note: format string is defined here
1267 | log_warn(LD_REND, "Client authorization file %s can't be read. "
| ^~
cc1: all warnings being treated as errors
make[1]: *** [Makefile:9877: src/feature/hs/hs_service.o] Error 1
CC src/feature/hs/core_libtor_app_testing_a-hs_service.o
In file included from ./src/lib/crypt_ops/crypto_rsa.h:21,
from ./src/core/or/or.h:32,
from src/feature/hs/hs_service.c:11:
In function ‘load_client_keys’,
inlined from ‘load_service_keys’ at src/feature/hs/hs_service.c:1090:7,
inlined from ‘hs_service_load_all_keys’ at src/feature/hs/hs_service.c:4010:9:
./src/lib/log/log.h:244:3: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
244 | log_fn_(LOG_WARN, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/feature/hs/hs_service.c:1267:7: note: in expansion of macro ‘log_warn’
1267 | log_warn(LD_REND, "Client authorization file %s can't be read. "
| ^~~~~~~~
src/feature/hs/hs_service.c: In function ‘hs_service_load_all_keys’:
src/feature/hs/hs_service.c:1267:52: note: format string is defined here
1267 | log_warn(LD_REND, "Client authorization file %s can't be read. "
| ^~
cc1: all warnings being treated as errors
make[1]: *** [Makefile:11111: src/feature/hs/core_libtor_app_testing_a-hs_service.o] Error 1
make[1]: Target 'all-am' not remade because of errors.
make[1]: Leaving directory '/home/nickm/src/tor-035'
make: *** [Makefile:5788: all] Error 2
[1016]$
```
It looks like this is a real bug: when there's something wrong with the client authorization file, we first free and null the file, and only log its contents afterwards.
This appears to affect 0.3.5 and later.Tor: 0.3.5.x-finalNick MathewsonNick Mathewson