Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:09Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33917Make IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL2020-06-13T15:53:09ZteorMake IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL... and DISABLE_ASSERTS_IN_UNIT_TESTS.
It's the only assertion/bug macro that doesn't support these debugging modes. Let's fix that.... and DISABLE_ASSERTS_IN_UNIT_TESTS.
It's the only assertion/bug macro that doesn't support these debugging modes. Let's fix that.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31374Appveyor: cast between incompatible function types in compat_time2020-06-13T15:44:11ZteorAppveyor: cast between incompatible function types in compat_timeThe latest Appveyor compiler complains:
{{{
../src/lib/time/compat_time.c:522:25: error: cast between incompatible function types from 'FARPROC' to 'ULONGLONG (__attribute__((stdcall)) *)(void)' [-Werror=cast-function-type]
522 | ...The latest Appveyor compiler complains:
{{{
../src/lib/time/compat_time.c:522:25: error: cast between incompatible function types from 'FARPROC' to 'ULONGLONG (__attribute__((stdcall)) *)(void)' [-Werror=cast-function-type]
522 | GetTickCount64_fn = (GetTickCount64_fn_t)
| ^
}}}
This issue is like #27465:
GetProcAddress() returns FARPROC, which is (long long int(*)()) on
64-bit Windows:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx
But GetTickCount64() is (long long unsigned int(*)()), on both 32-bit
and 64-bit Windows:
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount64
So gcc 8 issues a spurious "incompatible function pointer" warning
about the cast to GetTickCount64_fn_t.
Silence this warning by casting to a void function pointer, before
the cast to GetTickCount64_fn_t.
Fixes bug NNNNN; bugfix on 0.2.9.1-alpha.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29832Use the correct library names when UBSan isn't supported2020-06-13T15:39:39ZteorUse the correct library names when UBSan isn't supportedMore typosMore typosTor: unspecifiedteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29831Backport "enable expensive hardening message is wrong with static library bui...2020-06-13T15:39:38ZteorBackport "enable expensive hardening message is wrong with static library builds"If we backport #24558 to 0.2.9, then #29528 should be a trivial merge forward.If we backport #24558 to 0.2.9, then #29528 should be a trivial merge forward.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29830Use UndefinedBehaviorSanitizer when the UBSan configure checks pass, rather t...2020-06-13T15:39:38ZteorUse UndefinedBehaviorSanitizer when the UBSan configure checks pass, rather than the ASan configure checksconfigure: stop using UBSan when the compiler only supports ASan
When activating the undefined behaviour sanitiser (UBSan), configure.ac
checked the address sanitiser (ASan) variables, instead of the UBSan
variables.
Fixes bug ...configure: stop using UBSan when the compiler only supports ASan
When activating the undefined behaviour sanitiser (UBSan), configure.ac
checked the address sanitiser (ASan) variables, instead of the UBSan
variables.
Fixes bug (this one); bugfix on 0.2.9.1-alpha.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29823CID 1444117, CID 1444118 resource leaks in test_shared_random.c2020-06-13T15:39:36ZTaylor YuCID 1444117, CID 1444118 resource leaks in test_shared_random.c```
** CID 1444117: (RESOURCE_LEAK)
/src/test/test_shared_random.c: 1098 in test_utils_general()
/src/test/test_shared_random.c: 1099 in test_utils_general()
__________________________________________________________________________...```
** CID 1444117: (RESOURCE_LEAK)
/src/test/test_shared_random.c: 1098 in test_utils_general()
/src/test/test_shared_random.c: 1099 in test_utils_general()
________________________________________________________________________________________________________
*** CID 1444117: (RESOURCE_LEAK)
/src/test/test_shared_random.c: 1098 in test_utils_general()
1092 "1BDB7C3E973936E4D13A49F37C859B3DC69C429334CF9412E3FEF6399C52D47A";
1093 srv = tor_malloc_zero(sizeof(*srv));
1094 srv->num_reveals = 42;
1095 memcpy(srv->value, srv_value, sizeof(srv->value));
1096 dup_srv = sr_srv_dup(srv);
1097 tt_assert(dup_srv);
>>> CID 1444117: (RESOURCE_LEAK)
>>> Variable "dup_srv" going out of scope leaks the storage it points to.
1098 tt_u64_op(dup_srv->num_reveals, OP_EQ, srv->num_reveals);
1099 tt_mem_op(dup_srv->value, OP_EQ, srv->value, sizeof(srv->value));
1100 tor_free(srv);
1101 tor_free(dup_srv);
1102 }
1103
/src/test/test_shared_random.c: 1099 in test_utils_general()
1093 srv = tor_malloc_zero(sizeof(*srv));
1094 srv->num_reveals = 42;
1095 memcpy(srv->value, srv_value, sizeof(srv->value));
1096 dup_srv = sr_srv_dup(srv);
1097 tt_assert(dup_srv);
1098 tt_u64_op(dup_srv->num_reveals, OP_EQ, srv->num_reveals);
>>> CID 1444117: (RESOURCE_LEAK)
>>> Variable "dup_srv" going out of scope leaks the storage it points to.
1099 tt_mem_op(dup_srv->value, OP_EQ, srv->value, sizeof(srv->value));
1100 tor_free(srv);
1101 tor_free(dup_srv);
1102 }
1103
1104 /* Testing commitments_are_the_same(). Currently, the check is to test the
```
```
** CID 1444118: (RESOURCE_LEAK)
/src/test/test_shared_random.c: 1098 in test_utils_general()
/src/test/test_shared_random.c: 1099 in test_utils_general()
________________________________________________________________________________________________________
*** CID 1444118: (RESOURCE_LEAK)
/src/test/test_shared_random.c: 1098 in test_utils_general()
1092 "1BDB7C3E973936E4D13A49F37C859B3DC69C429334CF9412E3FEF6399C52D47A";
1093 srv = tor_malloc_zero(sizeof(*srv));
1094 srv->num_reveals = 42;
1095 memcpy(srv->value, srv_value, sizeof(srv->value));
1096 dup_srv = sr_srv_dup(srv);
1097 tt_assert(dup_srv);
>>> CID 1444118: (RESOURCE_LEAK)
>>> Variable "srv" going out of scope leaks the storage it points to.
1098 tt_u64_op(dup_srv->num_reveals, OP_EQ, srv->num_reveals);
1099 tt_mem_op(dup_srv->value, OP_EQ, srv->value, sizeof(srv->value));
1100 tor_free(srv);
1101 tor_free(dup_srv);
1102 }
1103
/src/test/test_shared_random.c: 1099 in test_utils_general()
1093 srv = tor_malloc_zero(sizeof(*srv));
1094 srv->num_reveals = 42;
1095 memcpy(srv->value, srv_value, sizeof(srv->value));
1096 dup_srv = sr_srv_dup(srv);
1097 tt_assert(dup_srv);
1098 tt_u64_op(dup_srv->num_reveals, OP_EQ, srv->num_reveals);
>>> CID 1444118: (RESOURCE_LEAK)
>>> Variable "srv" going out of scope leaks the storage it points to.
1099 tt_mem_op(dup_srv->value, OP_EQ, srv->value, sizeof(srv->value));
1100 tor_free(srv);
1101 tor_free(dup_srv);
1102 }
1103
1104 /* Testing commitments_are_the_same(). Currently, the check is to test the
```
These look to be only leaks in assertion-failure cases. Maybe make the pointers in question function-scope, or break stuff out into helper functions so the `done` label can properly clean up?Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29740Fix memory leaks in shared random unit tests: simple version2020-06-13T15:39:15ZteorFix memory leaks in shared random unit tests: simple versionPlease merge https://github.com/torproject/tor/pull/774 to the mainline branches.
I'll merge to to 0.2.9 and later after the mainline CI passes.Please merge https://github.com/torproject/tor/pull/774 to the mainline branches.
I'll merge to to 0.2.9 and later after the mainline CI passes.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29706Test failure due to memory leaks in shared-random unit tests: long-term fix2020-06-13T15:39:11ZteorTest failure due to memory leaks in shared-random unit tests: long-term fixIn #29599 we fixed some leaks in the shared-random unit tests. But there are still some test failures.
The shared random state claims to take over ownership of SRVs passed to it using PUT. But it doesn't free them automatically: instead...In #29599 we fixed some leaks in the shared-random unit tests. But there are still some test failures.
The shared random state claims to take over ownership of SRVs passed to it using PUT. But it doesn't free them automatically: instead, the caller has to remember to call state_del_current_srv() first. (Or one of its callers.)
The current app code is ok, but the test code doesn't always call the functions in the right order.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29703Backport test-network.sh fixes to 0.2.92020-06-13T15:39:10ZteorBackport test-network.sh fixes to 0.2.9In our 0.3.4 chutney CI, we get the chutney version of test-network.sh:
```
test-network.sh: using CHUTNEY_DNS_CONF '/dev/null'
test-network.sh: $TOR_DIR not set, trying $PWD
test-network.sh: $TOR_DIR is a Tor 0.3.4 or earlier build dire...In our 0.3.4 chutney CI, we get the chutney version of test-network.sh:
```
test-network.sh: using CHUTNEY_DNS_CONF '/dev/null'
test-network.sh: $TOR_DIR not set, trying $PWD
test-network.sh: $TOR_DIR is a Tor 0.3.4 or earlier build directory
```
https://travis-ci.org/torproject/tor/jobs/499382754#L3067
But in 0.2.9, we get the tor version of test-network.sh:
```
test-network.sh: Parsing command-line arguments to find $CHUTNEY_PATH
test-network.sh: $TOR_DIR not set, trying $PWD
Launching chutney using Python 2.7.6
```
https://travis-ci.org/torproject/tor/jobs/499382330#L2859
But tor 0.2.9's test-network.sh is meant to call chutney's test-network.sh.
We should fix this bug to make sure that we're getting consistent results from our CI. There are a lot of extra bug fixes in the latest chutney's test-network.sh, that aren't in tor 0.2.9's test-network.sh.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29643Fix an incorrect comment about calling FreeLibrary()2020-06-13T15:38:53ZteorFix an incorrect comment about calling FreeLibrary()There's an incorrect comment in compat_time.c about calling FreeLibrary().
See #29642 for background.There's an incorrect comment in compat_time.c about calling FreeLibrary().
See #29642 for background.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29640Improve the monotonic time documentation in compat_time.c2020-06-13T15:38:52ZteorImprove the monotonic time documentation in compat_time.cWe discovered in #29500 that the monotonic time documentation is incomplete. Here are some improvements we could make:
* define "monotonic" as "strictly non-decreasing, delta t >= 0"
* explain when 0 time deltas are more likely:
* when...We discovered in #29500 that the monotonic time documentation is incomplete. Here are some improvements we could make:
* define "monotonic" as "strictly non-decreasing, delta t >= 0"
* explain when 0 time deltas are more likely:
* when measuring units larger than nanoseconds (due to truncation on division)
* on platforms with low resolution timers (because two time calls can happen faster than the resolution of the timer)
* on Windows, where the time is not always monotonic, due to an OS bug
* on platforms without specialised monotonic functions, during a wall clock time change
* explain what happens when the timers overflow?
Based on:
​https://gitweb.torproject.org/tor.git/tree/src/lib/time/compat_time.c#n175
https://trac.torproject.org/projects/tor/ticket/29500#comment:11Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29599Test failure due to missing sr_state_free[_all]() in shared-random unit tests2020-06-13T15:38:38ZteorTest failure due to missing sr_state_free[_all]() in shared-random unit testsIt looks like Travis recently upgraded to a clang with a (better) LeakSanitizer.
The following tests have memory leaks:
* shared-random/vote
* shared-random/sr_compute_srv
* shared-random/state_transition
They are missing a call to sr_...It looks like Travis recently upgraded to a clang with a (better) LeakSanitizer.
The following tests have memory leaks:
* shared-random/vote
* shared-random/sr_compute_srv
* shared-random/state_transition
They are missing a call to sr_state_free() in 0.2.9 and later.
But it's spelt sr_state_free_all() in 0.3.3 and later.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/26924Make single onion service to rend and Tor2web to intro link authentication in...2020-06-13T15:28:35ZteorMake single onion service to rend and Tor2web to intro link authentication into a protocol warningSingle onion services and Tor2web connect directly to relays using untrusted link authentication keys.
These connections can cause a lot of warnings, particularly due to the link auth bugs in #26627.
We can either:
* downgrade all link...Single onion services and Tor2web connect directly to relays using untrusted link authentication keys.
These connections can cause a lot of warnings, particularly due to the link auth bugs in #26627.
We can either:
* downgrade all link auth warnings to protocol warnings on single onion services and Tor2web (this is the fast fix)
* taint untrusted link auth keys, and then downgrade connections using tainted keys to protocol warnings (this is very intrusive)Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/25784Misleading error message when asking for IPv6 in a network with no IPv6-capab...2020-06-13T15:24:23ZpastlyMisleading error message when asking for IPv6 in a network with no IPv6-capable exitsI created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
I didn't set `IPv6Exit 1` on any of the exits.
I had a client try to request `::1` over this Tor network on a hand crafted circuit (it makes sense to ask an e...I created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
I didn't set `IPv6Exit 1` on any of the exits.
I had a client try to request `::1` over this Tor network on a hand crafted circuit (it makes sense to ask an exit to connect to localhost when this is all local ... trust me). I got the following confusing error message on the client.
> [warn] I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's not going to work. Did you perhaps ask for an IPv6 address on an IPv4Only port, or vice versa?
I think it's important to point out (again) that I was hand crafting these circuits and was not considering IPv6 support. That said, I don't know what Tor would do if I let it make the circuit for me and it couldn't find an IPv6-supporting exit.
As you can see, I'm talking myself out of this being a bug and it just being me screwing things up for myself. I was encouraged to make a ticket though, so here we are.
If rewriting the error message is the solution, maybe after fixing the "fulfil" typo, we should add "It's also possible we couldn't find any exits supporting the IP version you want to use"
I'm picking 0.3.5.x-final just because I've been told you have to pick a milestone or else your tickets generally fall through the cracks. :)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25113monotonic_time unit test fail, 0.3.3.1-alpha debian armel2020-06-13T15:21:27ZRoger Dingledinemonotonic_time unit test fail, 0.3.3.1-alpha debian armel```
<weasel> util/monotonic_time:
<weasel> FAIL ../src/test/test_util.c:5843: assert(msecc1 OP_LE nsecc1 / 1000000 + 1): 41399 vs 41395
<weasel> [monotonic_time FAILED]
<weasel> https://buildd.debian.org/status/fetch.php?pkg=tor&arch...```
<weasel> util/monotonic_time:
<weasel> FAIL ../src/test/test_util.c:5843: assert(msecc1 OP_LE nsecc1 / 1000000 + 1): 41399 vs 41395
<weasel> [monotonic_time FAILED]
<weasel> https://buildd.debian.org/status/fetch.php?pkg=tor&arch=armel&ver=0.3.3.1-alpha-1&stamp=1517099318&raw=0
```
Looks like the armel build failed:
https://buildd.debian.org/status/package.php?p=tor&suite=experimental
The comment in the unit tests right above that is
```
/* We need to be a little careful here since we don't know the system load.
```
which makes me suspicious. :)Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24849Added -1 signatures to consensus2020-06-13T15:20:11ZteorAdded -1 signatures to consensusThis line is also in the logs from #24815.
```
Jan 09 08:57:32.637 [info] dirvote_add_signatures_to_pending_consensus: Added -1 signatures to consensus.
```This line is also in the logs from #24815.
```
Jan 09 08:57:32.637 [info] dirvote_add_signatures_to_pending_consensus: Added -1 signatures to consensus.
```Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24815Validate shared random state dates before each voting period2020-06-13T15:19:56ZteorValidate shared random state dates before each voting periodWhen tor's clock jumps, the shared random state can get out of sync with the current round.
This happens to me on a test authority on a laptop that sleeps regularly. But it could also happen to authorities that miss a voting round becau...When tor's clock jumps, the shared random state can get out of sync with the current round.
This happens to me on a test authority on a laptop that sleeps regularly. But it could also happen to authorities that miss a voting round because they are under heavy load. (I have seen clock jumps happen on Linux and BSD under the recent heavy load.)
I see this message when I restart my authority:
```
Jan 07 09:48:13.179 [info] or_state_load: Loaded state from "/Users/USER/tor/auth/auth-sr-3e/state"
Jan 07 09:48:14.977 [info] disk_state_validate: SR: Disk state valid after/until times are invalid.
Jan 07 09:48:14.984 [info] sr_state_update: SR: State prepared for upcoming voting period (2018-01-06 23:00:00). Upcoming phase is reveal (counters: 0 commit & 1 reveal rounds).
Jan 07 09:48:16.026 [info] or_state_save: Saved state to "/Users/USER/tor/auth/auth-sr-3e/state"
```
Even though this message was logged just before I killed it:
```
Jan 07 09:47:45.328 [info] or_state_save: Saved state to "/Users/USER/tor/auth/auth-sr-3e/state"
```Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/24740Tor launches two requests for authority certificates on first bootstrap2020-06-13T15:19:31ZteorTor launches two requests for authority certificates on first bootstrapWhen tor first bootstraps, it launches two requests for authority certificates:
* one is the hinted request that goes to the directory it downloaded the consensus from (ticket?)
* one is a scheduled request that goes to a random director...When tor first bootstraps, it launches two requests for authority certificates:
* one is the hinted request that goes to the directory it downloaded the consensus from (ticket?)
* one is a scheduled request that goes to a random directory
We should delay the first scheduled request slightly (5s?) to allow the first request to complete.
This might be as easy as changing the first number in the authority certificate schedule from 0 to 5.
I thought we avoided fetching certificates if another fetch was in progress: clearly that doesn't happen, and maybe we don't want it to, because we don't want to wait a whole 10 seconds for it to timeout.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23739improve documentation on how we use gcov2020-06-13T15:15:01ZTaylor Yuimprove documentation on how we use gcovTicket #16792 (0.2.9.1-alpha) introduced some automation for excluding lines from filtered gcov output. We should document the prefixes it uses to mark excluded lines. There should also be information about how to read the gcov-diff fi...Ticket #16792 (0.2.9.1-alpha) introduced some automation for excluding lines from filtered gcov output. We should document the prefixes it uses to mark excluded lines. There should also be information about how to read the gcov-diff files, which are processed to remove line numbers, among other things. We should also refer to the gcc documentation for gcov at https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.htmlTor: 0.3.2.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/22924signed integer overflow in unit tests crashes hardened build on 32-bit trusty2020-06-13T15:11:44ZNick Mathewsonsigned integer overflow in unit tests crashes hardened build on 32-bit trustyIf I build on gcc with --enable-fragile-hardening on ubuntu trusty, I get a crash in dir/download_status_random_backoff :
```
#0 0xf7fd9d70 in __kernel_vsyscall ()
#1 0xf6599827 in raise () from /lib/i386-linux-gnu/libc.so.6
#2 0xf65...If I build on gcc with --enable-fragile-hardening on ubuntu trusty, I get a crash in dir/download_status_random_backoff :
```
#0 0xf7fd9d70 in __kernel_vsyscall ()
#1 0xf6599827 in raise () from /lib/i386-linux-gnu/libc.so.6
#2 0xf659cc53 in abort () from /lib/i386-linux-gnu/libc.so.6
#3 0x56e5e16c in __addvsi3 ()
#4 0x5679e366 in download_status_random_backoff_helper (
min_delay=min_delay@entry=0, max_delay=max_delay@entry=2147483647)
at src/test/test_dir.c:4167
#5 0x5679e699 in test_dir_download_status_random_backoff (arg=0x0)
at src/test/test_dir.c:4196
#6 0x56a519dc in testcase_run_bare_ (
testcase=testcase@entry=0x5724e0c0 <dir_tests+640>)
at src/ext/tinytest.c:106
#7 0x56a51de1 in testcase_run_one (group=<optimized out>,
group@entry=0x572346b0 <testgroups+208>, testcase=<optimized out>,
testcase@entry=0x5724e0c0 <dir_tests+640>) at src/ext/tinytest.c:253
#8 0x56a532c4 in tinytest_main (c=2, v=0xffffd764,
groups=0x572345e0 <testgroups>) at src/ext/tinytest.c:435
#9 0x5661eede in main (c=2, v=<optimized out>)
at src/test/testing_common.c:319
```
I think this has something to do with our fixes for #17750 or #20534, but I'm not certain.
I have a patch that fixes this issue for me.Tor: 0.3.2.x-finalNick MathewsonNick Mathewson