Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:41:29Zhttps://gitlab.torproject.org/legacy/trac/-/issues/30475hs_service.c: compile-time warning with GCC 9.1.12020-06-13T15:41:29ZNick 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 Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30263make shellcheck expects scripts in the build directory2020-06-13T15:40:56Zteormake shellcheck expects scripts in the build directoryIn #28058, we added shellcheck for coverage and cov-diff. But we expect coverage to be in the build directory, which is wrong.
This fails the newest version of shellcheck in out-of-tree builds.In #28058, we added shellcheck for coverage and cov-diff. But we expect coverage to be in the build directory, which is wrong.
This fails the newest version of shellcheck in out-of-tree builds.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30004when reloading a consensus with a CRLF, log at notice.2020-06-13T15:40:13ZNick Mathewsonwhen reloading a consensus with a CRLF, log at notice.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29961Update the Tor version for bandwidth-file-digest in torspec2020-06-13T15:40:01ZteorUpdate the Tor version for bandwidth-file-digest in torspecSee my pull request:
https://github.com/torproject/torspec/pull/73See my pull request:
https://github.com/torproject/torspec/pull/73Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29959Actually include the bandwidth file digest in the vote2020-06-13T15:40:00ZteorActually include the bandwidth file digest in the voteThe original code in #26698 had a logic error, so the bandwidth file digest was never included in the vote.The original code in #26698 had a logic error, so the bandwidth file digest was never included in the vote.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29922util/time test failure on Jenkins2020-06-13T15:39:55ZAlexander 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/legacy/trac/-/issues/29884Document how to edit practracker exception files2020-06-13T15:39:47ZteorDocument how to edit practracker exception filesIt's really not clear how I should edit practracker exception files.
We should update the documentation at the start of practracker.py, update the warning message logged by practracker.py, and maybe update HelpfulTools.md.
Marking this...It's really not clear how I should edit practracker exception files.
We should update the documentation at the start of practracker.py, update the warning message logged by practracker.py, and maybe update HelpfulTools.md.
Marking this as 040-must, because it's blocking merges.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29874torrc no longer accepts space in executable paths2020-06-13T15:39:40Zcypherpunkstorrc no longer accepts space in executable pathsI'm not sure exactly when this change happened but 0.3.5.8 still works with a space in the executable path while 0.4.0.2 fails to launch the executable with the same torrc file.
The following is an example torrc line that no longer work...I'm not sure exactly when this change happened but 0.3.5.8 still works with a space in the executable path while 0.4.0.2 fails to launch the executable with the same torrc file.
The following is an example torrc line that no longer works:
ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec C:\Program Files\obfs4proxy.exe
Is this change documented somewhere? I'd like to keep the executable path unchanged if there is a simple workaroundTor: 0.4.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29693Decrease probability of stochastic failures in test-slow2020-06-13T15:39:05ZteorDecrease probability of stochastic failures in test-slowOur stochastic tests are supposed to fail around 1 in 100 runs. But when I'm doing a backport to 0.2.9, there are up to 14 jobs times 9 branches, each of which runs a test instance.
So let's decrease the probability to about 1 in (100 *...Our stochastic tests are supposed to fail around 1 in 100 runs. But when I'm doing a backport to 0.2.9, there are up to 14 jobs times 9 branches, each of which runs a test instance.
So let's decrease the probability to about 1 in (100 * 14 * 9).
Here's what the output looks like:
```
slow/prob_distr/stochastic_uniform: [forking] fail uniform sampler
FAIL src/test/test_prob_distr.c:1209: assert(ok)
NOTE: This is a stochastic test, and we expect it to fail from
time to time, with some low probability. If you see it fail more
than one trial in 100, though, please tell us.
Seed: 5DB9A3B32C29B76D7A0032700DD142BB
[stochastic_uniform FAILED]
```
https://travis-ci.org/torproject/tor/jobs/503432646#L5845Tor: 0.4.0.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/29562APPCRASH of tor.exe on Windows when PT bootstrap is cancelled2020-06-13T15:38:30ZDavid Fifielddcf@torproject.orgAPPCRASH of tor.exe on Windows when PT bootstrap is cancelled * [Tor Browser 8.5a8 64-bit](https://www.torproject.org/dist/torbrowser/8.5a8/torbrowser-install-win64-8.5a8_en-US.exe)
* tor 0.4.0.1-alpha 81f1b89efc94723f
* Windows 7
Start Tor Browser, click Configure, then select a pluggable tran... * [Tor Browser 8.5a8 64-bit](https://www.torproject.org/dist/torbrowser/8.5a8/torbrowser-install-win64-8.5a8_en-US.exe)
* tor 0.4.0.1-alpha 81f1b89efc94723f
* Windows 7
Start Tor Browser, click Configure, then select a pluggable transport (I tried both obfs4 and meek-azure). While bootstrapping is in progress, click Cancel. tor.exe crashes with the log:
```
[ERR] tor_assertion_failed_(): Bug: process.c:522: process_get_win32_process: Assertion process->win32_process failed; aborting. (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
[ERR] Bug: Assertion process->win32_process failed in process_get_win32_process at process.c:522. (Stack trace not available) (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
```
These dialogs appear in succession. Sometimes, the "application has requested the Runtime to terminate it in an unusual way" would not appear, and instead the "tor.exe has stopped working" would appear twice.
![terminate.png](uploads/terminate.png)
![stoppedworking.png](uploads/stoppedworking.png)
![exited.png](uploads/exited.png)
The "View problem details" expander shows:
```
Problem signature:
Problem Event Name: APPCRASH
Application Name: tor.exe
Application Version: 0.0.0.0
Application Timestamp: a640a628
Fault Module Name: tor.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: a640a628
Exception Code: 40000015
Exception Offset: 00000000002c6a44
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 869c
Additional Information 2: 869c6822c6babdacb5663a19facccafb
Additional Information 3: 607b
Additional Information 4: 607bd60f513aeecf36fa5e247b547f57
```
Here are tor logs from different runs. One of them mentions a clock skew, but that seems to be a problem with the remote system. I checked and the time on the local Windows host was correct.
```
2/23/19, 08:42:06.326 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:42:09.765 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:42:09.765 [NOTICE] Switching to guard context "default" (was using "bridges")
2/23/19, 08:42:09.765 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:42:09.765 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:42:09.765 [NOTICE] Opening Socks listener on 127.0.0.1:9150
2/23/19, 08:42:09.765 [NOTICE] Opened Socks listener on 127.0.0.1:9150
2/23/19, 08:42:10.224 [WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported: 2019/02/23 08:42:09 running firefox command ["C:\\Users\\david\\Desktop\\Tor Browser\\Browser\\firefox.exe" "--invisible" "-no-remote" "-profile" "C:\\Users\\david\\Desktop\\Tor Browser\\Browser\\TorBrowser\\Data\\Browser\\profile.meek-http-helper"]
2/23/19, 08:42:10.224 [WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported: 2019/02/23 08:42:09 firefox started with pid 3552
2/23/19, 08:42:10.224 [NOTICE] Bootstrapped 5% (conn): Connecting to a relay
2/23/19, 08:42:10.564 [WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported: 2019/02/23 08:42:10 running meek-client command ["TorBrowser\\Tor\\PluggableTransports\\meek-client.exe" "--helper" "127.0.0.1:1468"]
2/23/19, 08:42:10.565 [WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported: 2019/02/23 08:42:10 meek-client started with pid 4004
2/23/19, 08:42:10.565 [WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported: 2019/02/23 08:42:10 using helper on 127.0.0.1:1468
2/23/19, 08:42:10.565 [WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported: 2019/02/23 08:42:10 listening on 127.0.0.1:1469
2/23/19, 08:42:10.566 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
2/23/19, 08:42:10.892 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
2/23/19, 08:42:11.490 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done
2/23/19, 08:42:11.500 [NOTICE] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
2/23/19, 08:42:11.252 [NOTICE] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
2/23/19, 08:42:11.441 [NOTICE] Bootstrapped 30% (loading_status): Loading networkstatus consensus
2/23/19, 08:42:11.610 [WARN] Received NETINFO cell with skewed time (OR:128.31.0.39:9101): It seems that our clock is ahead by 7 hours, 59 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time, timezone, and date settings.
2/23/19, 08:42:11.610 [WARN] Problem bootstrapping. Stuck at 30% (loading_status): Loading networkstatus consensus. (Clock skew 28796 in NETINFO cell from OR; CLOCK_SKEW; count 1; recommendation warn; host 9695DFC35FFEB861329B9F1AB04C46397020CE31 at 128.31.0.39:9101)
2/23/19, 08:42:11.632 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
2/23/19, 08:42:11.632 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:42:11.633 [NOTICE] Delaying directory fetches: DisableNetwork is set.
2/23/19, 08:42:11.633 [ERR] tor_assertion_failed_(): Bug: process.c:522: process_get_win32_process: Assertion process->win32_process failed; aborting. (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
2/23/19, 08:42:11.634 [ERR] Bug: Assertion process->win32_process failed in process_get_win32_process at process.c:522. (Stack trace not available) (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
```
```
2/23/19, 08:47:29.840 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:47:29.840 [NOTICE] Opening Socks listener on 127.0.0.1:9150
2/23/19, 08:47:29.850 [NOTICE] Opened Socks listener on 127.0.0.1:9150
2/23/19, 08:47:30.850 [NOTICE] Bootstrapped 3% (conn_proxy): Connecting to proxy
2/23/19, 08:47:30.870 [NOTICE] Bootstrapped 4% (conn_done_proxy): Connected to proxy
2/23/19, 08:47:31.866 [WARN] Proxy Client: unable to connect to 37.218.240.34:40035 ("general SOCKS server failure")
2/23/19, 08:47:33.867 [WARN] Proxy Client: unable to connect to 37.218.240.34:40035 ("general SOCKS server failure")
2/23/19, 08:47:35.896 [WARN] Proxy Client: unable to connect to 37.218.240.34:40035 ("general SOCKS server failure")
2/23/19, 08:47:38.945 [WARN] Proxy Client: unable to connect to 37.218.240.34:40035 ("general SOCKS server failure")
2/23/19, 08:47:41.963 [WARN] Proxy Client: unable to connect to 37.218.240.34:40035 ("general SOCKS server failure")
2/23/19, 08:47:45.550 [WARN] Proxy Client: unable to connect to 37.218.240.34:40035 ("general SOCKS server failure")
2/23/19, 08:47:49.530 [WARN] Proxy Client: unable to connect to 37.218.240.34:40035 ("general SOCKS server failure")
2/23/19, 08:47:51.134 [WARN] Proxy Client: unable to connect to 154.35.22.9:443 ("general SOCKS server failure")
2/23/19, 08:47:51.136 [WARN] Proxy Client: unable to connect to 192.99.11.54:443 ("general SOCKS server failure")
2/23/19, 08:47:51.139 [WARN] Proxy Client: unable to connect to 154.35.22.11:443 ("general SOCKS server failure")
2/23/19, 08:47:51.141 [WARN] Proxy Client: unable to connect to 154.35.22.10:15937 ("general SOCKS server failure")
2/23/19, 08:47:51.142 [WARN] Proxy Client: unable to connect to 154.35.22.13:16815 ("general SOCKS server failure")
2/23/19, 08:47:51.143 [WARN] Proxy Client: unable to connect to 2001:470:b381:bfff:216:3eff:fe23:d6c3:443 ("general SOCKS server failure")
2/23/19, 08:47:51.144 [WARN] Proxy Client: unable to connect to 154.35.22.12:4304 ("general SOCKS server failure")
2/23/19, 08:47:57.239 [WARN] Proxy Client: unable to connect to 37.218.240.34:40035 ("general SOCKS server failure")
2/23/19, 08:48:04.848 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
2/23/19, 08:48:04.848 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:48:04.849 [ERR] tor_assertion_failed_(): Bug: process.c:522: process_get_win32_process: Assertion process->win32_process failed; aborting. (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
2/23/19, 08:48:04.849 [ERR] Bug: Assertion process->win32_process failed in process_get_win32_process at process.c:522. (Stack trace not available) (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
```
```
2/23/19, 08:52:16.607 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:52:23.234 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:52:23.234 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:52:23.235 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:52:23.235 [NOTICE] Opening Socks listener on 127.0.0.1:9150
2/23/19, 08:52:23.235 [NOTICE] Opened Socks listener on 127.0.0.1:9150
2/23/19, 08:52:24.231 [NOTICE] Bootstrapped 3% (conn_proxy): Connecting to proxy
2/23/19, 08:52:24.235 [NOTICE] Bootstrapped 4% (conn_done_proxy): Connected to proxy
2/23/19, 08:52:26.212 [WARN] Proxy Client: unable to connect to 37.218.240.34:40035 ("general SOCKS server failure")
2/23/19, 08:52:28.800 [WARN] Proxy Client: unable to connect to 37.218.240.34:40035 ("general SOCKS server failure")
2/23/19, 08:52:28.810 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
2/23/19, 08:52:28.820 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/23/19, 08:52:28.820 [ERR] tor_assertion_failed_(): Bug: process.c:522: process_get_win32_process: Assertion process->win32_process failed; aborting. (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
2/23/19, 08:52:28.820 [ERR] Bug: Assertion process->win32_process failed in process_get_win32_process at process.c:522. (Stack trace not available) (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
```Tor: 0.4.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29550Tor nightly fails to build for Windows2020-06-13T15:38:28ZboklmTor nightly fails to build for WindowsSince 2019-02-15, tor fails to build for Windows inside the Tor Browser nightly builds.
It fails with this error:
```
CCLD src/tools/tor-gencert.exe
CCLD src/test/test-switch-id.exe
CCLD src/test/test-timers.exe
CCLD...Since 2019-02-15, tor fails to build for Windows inside the Tor Browser nightly builds.
It fails with this error:
```
CCLD src/tools/tor-gencert.exe
CCLD src/test/test-switch-id.exe
CCLD src/test/test-timers.exe
CCLD src/test/test-bt-cl.exe
CCLD src/test/test-rng.exe
CCLD src/test/fuzz/fuzz-consensus.exe
CCLD src/test/fuzz/fuzz-descriptor.exe
CCLD src/test/fuzz/fuzz-diff.exe
CCLD src/test/fuzz/fuzz-diff-apply.exe
CCLD src/test/fuzz/fuzz-extrainfo.exe
CCLD src/test/fuzz/fuzz-hsdescv2.exe
CCLD src/test/fuzz/fuzz-hsdescv3.exe
CCLD src/test/fuzz/fuzz-http.exe
CCLD src/test/fuzz/fuzz-http-connect.exe
CCLD src/test/fuzz/fuzz-iptsv2.exe
CCLD src/test/fuzz/fuzz-microdesc.exe
CCLD src/test/fuzz/fuzz-socks.exe
CCLD src/test/fuzz/fuzz-strops.exe
CCLD src/test/fuzz/fuzz-vrs.exe
CCLD src/app/tor.exe
CCLD src/tools/tor-resolve.exe
CCLD src/tools/tor-print-ed-signing-cert.exe
CCLD src/test/bench.exe
CCLD src/test/test.exe
CCLD src/test/test-slow.exe
/var/tmp/dist/mingw-w64/lib/gcc/i686-w64-mingw32/6.4.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status
make[1]: *** [src/test/test-slow.exe] Error 1
Makefile:8673: recipe for target 'src/test/test-slow.exe' failed
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/var/tmp/build/tor-59c3910becd9'
Makefile:5290: recipe for target 'all' failed
make: *** [all] Error 2
```Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29538Coverage fails on master2020-06-13T15:38:24ZteorCoverage fails on masterSince about 24 hours ago, coveralls is failing.
The bot isn't posting GitHub comments, and coveralls.io has some builds, with no coverage data.
The last pull request with a bot comment was at 14:39 UTC on 17 Feb:
https://github.com/torp...Since about 24 hours ago, coveralls is failing.
The bot isn't posting GitHub comments, and coveralls.io has some builds, with no coverage data.
The last pull request with a bot comment was at 14:39 UTC on 17 Feb:
https://github.com/torproject/tor/pull/708
Sometimes, the repository isn't found:
```
{u'message': u"Couldn't find a repository matching this job.", u'error': True}
```
https://travis-ci.org/torproject/tor/jobs/495420447#L7333
Sometimes, the coverage is uploaded, but the analysis has no data:
```
{u'url': u'https://coveralls.io/jobs/45356536', u'message': u'Job #3861.6'}
```
https://travis-ci.org/torproject/tor/jobs/495759411#L7330
https://coveralls.io/jobs/45356536
I don't know if this is a coveralls failure, a Travis failure, a GitHub failure, or a change in our code.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29529util/map_anon_nofork test fails on macOS2020-06-13T15:38:19Zteorutil/map_anon_nofork test fails on macOSI get the following error on macOS:
```
util/map_anon_nofork:
FAIL ../src/test/test_util.c:6209: assert(r OP_LE 0): 1 vs 0
[map_anon_nofork FAILED]
```I get the following error on macOS:
```
util/map_anon_nofork:
FAIL ../src/test/test_util.c:6209: assert(r OP_LE 0): 1 vs 0
[map_anon_nofork FAILED]
```Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29527Division by zero: undefined behaviour in circuitpadding/circuitpadding_sample...2020-06-13T15:38:16ZteorDivision by zero: undefined behaviour in circuitpadding/circuitpadding_sample_distribution testWhen running the tor unit tests on macOS with `--enable-expensive-hardening`, I get the following error:
```
circuitpadding/circuitpadding_sample_distribution: [forking] ../src/lib/math/prob_distr.c:1311:17: runtime error: division by ze...When running the tor unit tests on macOS with `--enable-expensive-hardening`, I get the following error:
```
circuitpadding/circuitpadding_sample_distribution: [forking] ../src/lib/math/prob_distr.c:1311:17: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/lib/math/prob_distr.c:1311:17 in
../src/lib/math/prob_distr.c:1219:49: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/lib/math/prob_distr.c:1219:49 in
OK
```
My full configure command-line is:
```
configure --disable-asciidoc --with-libevent-dir=/usr/local --with-openssl-dir=/usr/local/opt/openssl --enable-lzma --enable-zstd --enable-libscrypt CC=clang --enable-gcc-warnings --enable-expensive-hardening PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig
```Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29500Broken circuitpadding unittests on appveyor2020-06-13T15:40:08ZGeorge KadianakisBroken circuitpadding unittests on appveyorThis x86 appveyor build failed two unittests: https://ci.appveyor.com/project/torproject/tor/builds/22350196/job/457arqlgfgf6b0a3
```
circuitpadding/circuitpadding_tokens: [forking]
FAIL ../src/test/test_circuitpadding.c:1125: assert...This x86 appveyor build failed two unittests: https://ci.appveyor.com/project/torproject/tor/builds/22350196/job/457arqlgfgf6b0a3
```
circuitpadding/circuitpadding_tokens: [forking]
FAIL ../src/test/test_circuitpadding.c:1125: assert(mi->histogram[4] OP_EQ 2): 0 vs 2
[circuitpadding_tokens FAILED]
circuitpadding/circuitpadding_rtt: [forking]
FAIL ../src/test/test_circuitpadding.c:324: assert(relay_side->padding_info[0]->last_received_time_usec OP_NE 0): 0 vs 0
[circuitpadding_rtt FAILED]
```Tor: 0.4.0.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/29357add an ActiveOnStartup config option2020-06-13T15:37:57ZMark Smithadd an ActiveOnStartup config optionWhen Tor Browser starts tor, it does not make sense to start in dormant mode (the browser is an interactive application which people will typically immediately begin using to surf the web). It would be very helpful if tor had an `ActiveO...When Tor Browser starts tor, it does not make sense to start in dormant mode (the browser is an interactive application which people will typically immediately begin using to surf the web). It would be very helpful if tor had an `ActiveOnStartup` Boolean config option which would ensure that tor starts in active mode.
Related: #29045Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29354Update bandwidth-file-spec.txt with the country keyword2020-06-13T15:37:56ZjugaUpdate bandwidth-file-spec.txt with the country keywordTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29168Fix TROVE-2019-001 (KIST can write above outbuf highwater mark)2020-06-13T15:37:11ZNick MathewsonFix TROVE-2019-001 (KIST can write above outbuf highwater mark)From the fix in be84ed1a64ed7ce810bd3924fa96c2588b491ef5:
```
KIST works by computing how much should be allowed to write to the kernel for
a given socket, and then it writes that amount to the outbuf.
The problem is tha...From the fix in be84ed1a64ed7ce810bd3924fa96c2588b491ef5:
```
KIST works by computing how much should be allowed to write to the kernel for
a given socket, and then it writes that amount to the outbuf.
The problem is that it could be possible that the outbuf already has lots of
data in it from a previous scheduling round (because the kernel is full/busy
and Tor was not able to flush the outbuf yet). KIST ignores that the outbuf
has been filling (is above its "highwater") and writes more anyway. The end
result is that the outbuf length would exceed INT_MAX, hence causing an
assertion error and a corresponding "Bug()" message to get printed to the
logs.
This commit makes it for KIST to take into account the outbuf length when
computing the available space.
```Tor: 0.4.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29136PT_LOG and PT_STATUS event fields unspecifed2020-06-13T15:37:03ZDamian JohnsonPT_LOG and PT_STATUS event fields unspecifedRecently Tor added PT_LOG and PT_STATUS events to the spec...
https://gitweb.torproject.org/torspec.git/commit/?id=3028cf1
https://gitweb.torproject.org/torspec.git/commit/?id=b38257e
Unfortunately the 'pt-spec.txt section 3.3.5' secti...Recently Tor added PT_LOG and PT_STATUS events to the spec...
https://gitweb.torproject.org/torspec.git/commit/?id=3028cf1
https://gitweb.torproject.org/torspec.git/commit/?id=b38257e
Unfortunately the 'pt-spec.txt section 3.3.5' section they mention does not exist, and in looking around I can't find anything that describes what these event fields are defined as ('PT=' 'TYPE=', 'CONNECT=', etc).
I started to write a stem parser for these but can't continue until this is done (I can't parse events without knowing what fields they include).
David is aware of this and plans to has kindly offered to add the missing info...
```
22:24 <+atagar> dgoulet: Your control-spec addition to descript PT_LOG and PT_STATUS
cite a pt-spec section 3.3.4 which does not exist.
22:24 <+atagar> s/descript/describe
22:29 <+atagar> dgoulet: Huh. I'm not spotting anything that lists the keyword
arguments ('PT=' and 'SEVERITY=') so guess the sections simply
missing from the spec. I need that for stem support so please
give me a nudge when the event spec's done. :)
22:59 <+dgoulet> atagar: oh hmmm I'll fix that sorry
23:17 <+atagar> Thanks! Much appreciated. :)
```Tor: 0.4.4.x-finalDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28984Update dir-spec observed bandwidth to 5 days2020-06-13T15:36:14ZteorUpdate dir-spec observed bandwidth to 5 daysIn #23856 we accidentally updated the observed bandwidth to 5 days from 1 day. It's a good change for privacy, and it doesn't seem to affect load-balancing too much.
So let's update the spec, and review as part of sbws 1.1.In #23856 we accidentally updated the observed bandwidth to 5 days from 1 day. It's a good change for privacy, and it doesn't seem to affect load-balancing too much.
So let's update the spec, and review as part of sbws 1.1.Tor: 0.4.0.x-finalteorteor