The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:50:52Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29536prng: Add a global fast PRNG object2020-06-27T13:50:52ZDavid Gouletdgoulet@torproject.orgprng: Add a global fast PRNG objectprop289 needs to have a fast PRNG allocated early in order to avoid creating a fast prng object every time we want to add random to a cell.prop289 needs to have a fast PRNG allocated early in order to avoid creating a fast prng object every time we want to add random to a cell.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29534Regression: map_anon_nofork test is breaking jenkins on some platforms2020-06-27T13:50:52ZNick MathewsonRegression: map_anon_nofork test is breaking jenkins on some platformsThis test from the fast_rng branch is breaking jenkins CI in some cases:
```
17:39:20 util/map_anon_nofork:
17:39:20 FAIL ../tor/src/test/test_util.c:6206: assert((int)r OP_EQ 1): 0 vs 1
17:39:20 [map_anon_nofork FAILED]
```
I sus...This test from the fast_rng branch is breaking jenkins CI in some cases:
```
17:39:20 util/map_anon_nofork:
17:39:20 FAIL ../tor/src/test/test_util.c:6206: assert((int)r OP_EQ 1): 0 vs 1
17:39:20 [map_anon_nofork FAILED]
```
I suspect this is about kernel/header mismatch, but I need to check more closely.
I think we should disable this test in 0.4.0 (since the code is unused) and look for better solutions in 0.4.1.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29533Lint all our shell scripts with shellcheck on CI2020-06-27T13:50:52Zrl1987Lint all our shell scripts with shellcheck on CIWe have stuff in scripts directory being linted by shellcheck on every CI run, but not stuff in e.g. tests/ and contrib/. We should do so when we are done systematically cleaning up our shell scripts to make them pass shellcheck without ...We have stuff in scripts directory being linted by shellcheck on every CI run, but not stuff in e.g. tests/ and contrib/. We should do so when we are done systematically cleaning up our shell scripts to make them pass shellcheck without any warnings.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29532Update pre-push hook so that only maint-* and release-* can get pushed to ori...2020-06-27T13:50:52ZNick MathewsonUpdate pre-push hook so that only maint-* and release-* can get pushed to origin.See legacy/trac#29531 for motivation
Edit: correct ticketSee legacy/trac#29531 for motivation
Edit: correct ticketTor: 0.4.1.x-finalrl1987rl1987https://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/29529util/map_anon_nofork test fails on macOS2020-06-27T13:50:53Zteorutil/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/tpo/core/tor/-/issues/29528UndefinedBehaviorSanitizer errors should fail the unit tests2022-09-01T21:29:27ZteorUndefinedBehaviorSanitizer errors should fail the unit testsIn legacy/trac#29527, clang's UndefinedBehaviorSanitizer logs a failure, but the unit test succeeds.
We should fail the unit tests on sanitizer errors. (There might be an environmental variable to fail on errors?)In legacy/trac#29527, clang's UndefinedBehaviorSanitizer logs a failure, but the unit test succeeds.
We should fail the unit tests on sanitizer errors. (There might be an environmental variable to fail on errors?)https://gitlab.torproject.org/tpo/core/tor/-/issues/29527Division by zero: undefined behaviour in circuitpadding/circuitpadding_sample...2020-06-27T13:50:53ZteorDivision 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/tpo/core/tor/-/issues/29521Update test descriptors, and work out how to keep them updated2021-09-16T14:24:10ZteorUpdate test descriptors, and work out how to keep them updatedTor's unit tests contain a bunch of test descriptors: router descriptors, extrainfo descriptors, votes, and onion service descriptors.
But these descriptors go out of date over time, because we don't keep them updated.
For example, EX_...Tor's unit tests contain a bunch of test descriptors: router descriptors, extrainfo descriptors, votes, and onion service descriptors.
But these descriptors go out of date over time, because we don't keep them updated.
For example, EX_EI_MAXIMAL in src/test/example_extrainfo.inc is no longer maximal, because we added PaddingStatistics (and maybe other statistics).
Ideally, we need:
1. tests for the oldest supported minimal and maximal descriptors
2. tests for significant changes in the minimal and maximal descriptors
3. tests for the current version's minimal and maximal descriptors
4. a test that fails if we forget to update the test descriptors for a new feature
We could implement 1 & 2 by storing minimal and maximal descriptors from each supported Tor version. We could test 3 by generating and parsing the descriptors as part of the test, and 4 by checking for new fields in the generated descriptor, that are missing from the latest stored descriptor.
Maybe we also want a test that old versions can parse newer descriptors?
We could store an archive of supported descriptors, and test it against every supported Tor version using CI and a (Travis) cron job.https://gitlab.torproject.org/tpo/core/tor/-/issues/29520Makefile: let target "micro-revision.i" be a prerequisite of the default target2022-09-01T21:29:27ZtoralfMakefile: let target "micro-revision.i" be a prerequisite of the default targetRealized today, that a "make fuzzers" after a "make distclean" won't work due to
```
src/lib/version/git_revision.c:15:10: fatal error: micro-revision.i: No such file or directory
```
(tested at tor-0.4.0.1-alpha-98-g6c173d00f)Realized today, that a "make fuzzers" after a "make distclean" won't work due to
```
src/lib/version/git_revision.c:15:10: fatal error: micro-revision.i: No such file or directory
```
(tested at tor-0.4.0.1-alpha-98-g6c173d00f)https://gitlab.torproject.org/tpo/core/tor/-/issues/29519Tor from Git on FreeBSD: cc src/test/test-slow leads to "/usr/bin/ld: error: ...2020-06-27T13:50:53ZNeel Chauhanneel@neelc.orgTor from Git on FreeBSD: cc src/test/test-slow leads to "/usr/bin/ld: error: unable to find library -levent"When I compile Tor from Git (6c173d00f5ecba150b1a70a68de6102428d65f51) on FreeBSD, I get this error:
```
neel@xb3:~/code/tor/tor % make
make all-am
CCLD src/test/test-slow
/usr/bin/ld: error: unable to find library -levent
cc: er...When I compile Tor from Git (6c173d00f5ecba150b1a70a68de6102428d65f51) on FreeBSD, I get this error:
```
neel@xb3:~/code/tor/tor % make
make all-am
CCLD src/test/test-slow
/usr/bin/ld: error: unable to find library -levent
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1
Stop.
make[1]: stopped in /usr/home/neel/code/tor/tor
*** Error code 1
Stop.
make: stopped in /usr/home/neel/code/tor/tor
neel@xb3:~/code/tor/tor %
```
This error exists on 11.2 and 12.0.Tor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/29508KIST does not check the right channel's sched_heap_idx when readding channels2020-06-27T13:50:53ZpastlyKIST does not check the right channel's sched_heap_idx when readding channelsLink to the section of code as of right now: https://gitweb.torproject.org/tor.git/tree/src/core/or/scheduler_kist.c#n724
The buggy code
```
/* Re-add any channels we need to */
if (to_readd) {
SMARTLIST_FOREACH_BEGIN(to_readd,...Link to the section of code as of right now: https://gitweb.torproject.org/tor.git/tree/src/core/or/scheduler_kist.c#n724
The buggy code
```
/* Re-add any channels we need to */
if (to_readd) {
SMARTLIST_FOREACH_BEGIN(to_readd, channel_t *, readd_chan) {
scheduler_set_channel_state(readd_chan, SCHED_CHAN_PENDING);
if (!smartlist_contains(cp, readd_chan)) {
if (!SCHED_BUG(chan->sched_heap_idx != -1, chan)) {
/* XXXX Note that the check above is in theory redundant with
* the smartlist_contains check. But let's make sure we're
* not messing anything up, and leave them both for now. */
smartlist_pqueue_add(cp, scheduler_compare_channels,
offsetof(channel_t, sched_heap_idx), readd_chan);
}
}
} SMARTLIST_FOREACH_END(readd_chan);
smartlist_free(to_readd);
}
```
The code wrapped in`SCHED_BUG` should be checking `readd_chan` not `chan`.
This has never been an issue in mainline-Tor because the scheduler never leaves its while loop with channels in `channels_pending`. But if you make changes to Tor's code that allow for the scheduler to leave its loop without emptying `channels_pending`, then this condition will often fail, which cumulates in tor ultimately seemingly forgetting about the channel and letting it sit idle.
Branch incoming.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29501tor: Unhandled OpenSSL errors found2022-06-17T16:06:53Zweasel (Peter Palfrader)tor: Unhandled OpenSSL errors foundvia [[https://bugs.debian.org/922237|Debian#922237]]:
From syslog:
```
Feb 13 15:14:33 tglase-nb Tor[1770]: Bootstrapped 80%: Connecting to the Tor network
Feb 13 15:14:33 tglase-nb Tor[1770]: Unhandled OpenSSL errors found at ../src/l...via [[https://bugs.debian.org/922237|Debian#922237]]:
From syslog:
```
Feb 13 15:14:33 tglase-nb Tor[1770]: Bootstrapped 80%: Connecting to the Tor network
Feb 13 15:14:33 tglase-nb Tor[1770]: Unhandled OpenSSL errors found at ../src/lib/tls/tortls_openssl.c:1043:
Feb 13 15:14:33 tglase-nb Tor[1770]: TLS error: bad value (in SSL routines:ssl_do_config:---)
Feb 13 15:14:33 tglase-nb Tor[1770]: Bootstrapped 90%: Establishing a Tor circuit
```
It seems to be only a warning, but thought you might wish to know.https://gitlab.torproject.org/tpo/core/tor/-/issues/29500Broken circuitpadding unittests on appveyor2020-06-27T13:50:54ZGeorge 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/tpo/core/tor/-/issues/29499permission error: nyx requires executable permission bit for `/var/lib/tor`2020-07-29T03:12:05Zcypherpunkspermission error: nyx requires executable permission bit for `/var/lib/tor`Offending logs from strace:
```
stat("/var/lib/tor/control_auth_cookie", 0x7ffca7ba61f0) = -1 EACCES (Permission denied)
stat("/var/lib/tor/control_auth_cookie", 0x7ffca7ba61f0) = -1 EACCES (Permission denied)
write(1, "We were unable to...Offending logs from strace:
```
stat("/var/lib/tor/control_auth_cookie", 0x7ffca7ba61f0) = -1 EACCES (Permission denied)
stat("/var/lib/tor/control_auth_cookie", 0x7ffca7ba61f0) = -1 EACCES (Permission denied)
write(1, "We were unable to read tor's aut"..., 176We were unable to read tor's authentication cookie...
Path: /var/lib/tor/control_auth_cookie
Issue: Authentication failed: '/var/lib/tor/control_auth_cookie' doesn't exist) = 176
```
Permissions on /var/lib/tor:
` drwx------ 3 tor tor 4.0K Feb 14 17:04 tor `
Permissions for cookie file:
` -rw-r----- 1 tor tor 32 Feb 13 06:36 control_auth_cookie `
A quick fix on the user part is to add the executable bit for group, but in general the cookie file should be accessible without the executable bit set so as long as the cookie file is configured to be readable by group (i.e. 'CookieAuthFileGroupReadable 1' written in /etc/tor/torrc).Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29496DOS2020-06-27T13:50:54ZTracDOSHi<
New to the Wiki, I'm having a awful time with DOS,any help would be greatly appreciated.Thanks
**Trac**:
**Username**: bassHi<
New to the Wiki, I'm having a awful time with DOS,any help would be greatly appreciated.Thanks
**Trac**:
**Username**: basshttps://gitlab.torproject.org/tpo/core/tor/-/issues/29494Optimize interaction between circuitmux and circuitpadding2022-06-17T18:10:30ZMike PerryOptimize interaction between circuitmux and circuitpaddingIn legacy/trac#29204, we realized that we needed to inspect the circuit queue to prevent the circuit padding system from queuing too much padding. For that ticket, we're going to do the simple fix -- we don't schedule padding if the circ...In legacy/trac#29204, we realized that we needed to inspect the circuit queue to prevent the circuit padding system from queuing too much padding. For that ticket, we're going to do the simple fix -- we don't schedule padding if the circuit's cell queue already has a window full of cells on it. In that case, we just lie to circpad and tell the machine we sent padding even though we did not.
However, we should determine if we want to have a more complicated interaction, such as delaying our padding until the queue drains. We should also examine creating alternate machine events for when cells are dequeued from circuitmux vs when they are sent locally. This has pluses and minuses for machine interaction.https://gitlab.torproject.org/tpo/core/tor/-/issues/29491Chutney fails when Tor is built with --enable-nss2022-06-17T13:04:07ZNick MathewsonChutney fails when Tor is built with --enable-nssWe should get chutney passing when Tor is built with --enable-nss. Currently, it fails for two reasons:
* tor-gencert is not built with NSS.
* If you use a copy of a working tor-gencert, some of the chutney tests fail.We should get chutney passing when Tor is built with --enable-nss. Currently, it fails for two reasons:
* tor-gencert is not built with NSS.
* If you use a copy of a working tor-gencert, some of the chutney tests fail.https://gitlab.torproject.org/tpo/core/tor/-/issues/29490Chutney fails (sometimes?) when tor is built with --enable-coverage2022-06-17T13:03:58ZNick MathewsonChutney fails (sometimes?) when tor is built with --enable-coverageRight now we can't enable chutney on Travis when Tor is built with --enable-coverage. This appears to be relating to timing issues with consensus generation. I can reproduce this behavior on my desktop.Right now we can't enable chutney on Travis when Tor is built with --enable-coverage. This appears to be relating to timing issues with consensus generation. I can reproduce this behavior on my desktop.https://gitlab.torproject.org/tpo/core/tor/-/issues/29488Consider renaming all bash scripts to have .bash extension2020-07-29T02:56:27Zrl1987Consider renaming all bash scripts to have .bash extensionTor: unspecified