The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-09-01T21:29:27Zhttps://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: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29487SOCKS5 handshake fail when client sending user/pass auth method2020-06-27T13:50:55ZTracSOCKS5 handshake fail when client sending user/pass auth methodAfter updating Tor to 0.3.5.7 on my Debian system, Proxychains won't connect to Tor via SOCKS5 (SOCKS4 works normally). In handshake, proxychains sents auth methods "no auth" and "user/pass", Tor selects "user/pass", proxychains sents em...After updating Tor to 0.3.5.7 on my Debian system, Proxychains won't connect to Tor via SOCKS5 (SOCKS4 works normally). In handshake, proxychains sents auth methods "no auth" and "user/pass", Tor selects "user/pass", proxychains sents empty username and pass, Tor returns success status, proxychains sents connection request, Tor returns general failure status. If application don't send "user/pass" auth method, Tor selects "no auth" in socks handshake and connection establishes normally.
In log:
Tor[]: socks5: parsing failed - invalid user/pass authentication message.
Tor[]: Fetching socks handshake failed. Closing.
Wireshark log is in attachment.
Sorry for bad English.
**Trac**:
**Username**: access_deniedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29485guidelines for POSIX sh vs bash2020-07-29T03:00:17ZTaylor Yuguidelines for POSIX sh vs bashWe should decide whether we want our shell scripts to be in POSIX sh or bash, and document this. See legacy/trac#28106 for some rationale for staying with POSIX sh. This should probably go in doc/HACKING/WritingTests.md.We should decide whether we want our shell scripts to be in POSIX sh or bash, and document this. See legacy/trac#28106 for some rationale for staying with POSIX sh. This should probably go in doc/HACKING/WritingTests.md.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29478Update to February GeoIP2 database2020-06-27T13:50:55ZKarsten LoesingUpdate to February GeoIP2 database[My geoip-2019-02-05 branch](https://gitweb.torproject.org/user/karsten/tor.git/log/?h=geoip-2019-02-05) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other b...[My geoip-2019-02-05 branch](https://gitweb.torproject.org/user/karsten/tor.git/log/?h=geoip-2019-02-05) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branches that are still maintained.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29439Refactoring: Make SOCKS server state machine explicitly defined2022-06-17T17:39:18Zrl1987Refactoring: Make SOCKS server state machine explicitly defined> * State should be kept explicitly. Let's forget this "if the socks version is set, we've parsed this much, ..." business.
> * The function should dispatch first on state, next on anything else.
This was supposed to be done as part of...> * State should be kept explicitly. Let's forget this "if the socks version is set, we've parsed this much, ..." business.
> * The function should dispatch first on state, next on anything else.
This was supposed to be done as part of legacy/trac#3569, but wasn't. We should do it anyway.https://gitlab.torproject.org/tpo/core/tor/-/issues/29438In socks-extensions.txt document how we diverge from IETF RFCs for SOCKS5/5a2020-06-27T13:50:55Zrl1987In socks-extensions.txt document how we diverge from IETF RFCs for SOCKS5/5aFor example, we violate RFC1929 by allowing empty usernames/passwords.
Things like that should be documented.For example, we violate RFC1929 by allowing empty usernames/passwords.
Things like that should be documented.Tor: 0.4.1.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/29437test-stem times out intermittently2020-06-27T13:50:55Zrl1987test-stem times out intermittently```
control.base_controller... success (1.23s)
control.controller...
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wron...```
control.base_controller... success (1.23s)
control.controller...
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated
```
https://travis-ci.org/rl1987/tor/jobs/490611608Tor: 0.4.3.x-finalNick MathewsonNick Mathewson