Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:52:43Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33782Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions2020-06-13T15:52:43ZTracIncreases TEST_CONN_FD_INIT to make tests working on GitHub ActionsWith the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_soc...With the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_socket__real: Non-fatal assertion n_sockets_open >= 0 failed. (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: Tor 0.4.2.5: Non-fatal assertion n_sockets_open >= 0 failed in tor_close_socket__real at src/lib/net/socket.c:237. Stack trace: (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(log_backtrace_impl+0x56) [0x55d2831c7696] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_bug_occurred_+0x17f) [0x55d2831c2fcf] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_close_socket__real+0xd7) [0x55d2831ba3f7] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(connection_free_minimal+0x1c7) [0x55d28302a507] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x2d5dff) [0x55d282e91dff] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x444c66) [0x55d283000c66] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(testcase_run_one+0x2f1) [0x55d283000fb1] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tinytest_main+0x10c) [0x55d28300156c] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(main+0x2a0) [0x55d282cad9f0] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f65fdf83b97] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(_start+0x2a) [0x55d282cadb1a] (on Tor 0.4.2.5 )
[e2e_rend_circuit_setup_legacy FAILED]
```
The reason is because of a process running in GitHub Actions doing something that caused a lot of file descriptors to open. So, when Tor is trying to close a fake socket it ends up closing a real one that was opened by GitHub Actions.
I already tried with 100 and it does not work. So I tried 200 and it works.
**Trac**:
**Username**: ultimaweaponTor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27096Stop relying on $HOME being set in the unit tests2020-06-13T15:29:15ZteorStop relying on $HOME being set in the unit testsWhen I test Tor with $HOME unset, I see the following error:
```
options/validate__uname_for_server: [forking]
FAIL ../src/test/test_options.c:507: expected log to not contain entries Captured logs:
1. warn: "Couldn\'t find $HOME...When I test Tor with $HOME unset, I see the following error:
```
options/validate__uname_for_server: [forking]
FAIL ../src/test/test_options.c:507: expected log to not contain entries Captured logs:
1. warn: "Couldn\'t find $HOME environment variable while expanding \"~/.tor\"; defaulting to \"\".\n"
2. warn: "Default DataDirectory is \"~/.tor\". This expands to \"/.tor\", which is probably not what you want. Using \"/usr/local/var/tor\" instead\n"
[validate__uname_for_server FAILED]
```
This test has been around since 0.2.8.1-alpha.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24708Make the fallback script search harder for python2020-06-13T16:06:15ZteorMake the fallback script search harder for pythonSome OSs don't put python in /usr/bin. pastly will tell you this.Some OSs don't put python in /usr/bin. pastly will tell you this.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/24681Make the default fallback weight in Tor 10.02020-06-13T15:19:15ZteorMake the default fallback weight in Tor 10.0This is a follow-up to #24679.
* update the default weight in parse_dir_fallback_line() to 10.0
* update the man page to reflect the new default
10.0 gives us:
* 0.5% clients bootstrapping off an authority when all fallbacks are up, * ...This is a follow-up to #24679.
* update the default weight in parse_dir_fallback_line() to 10.0
* update the man page to reflect the new default
10.0 gives us:
* 0.5% clients bootstrapping off an authority when all fallbacks are up, * 2% when 25% are down (our replacement threshold)
* 7% when 40% are down (our worst case scenario)Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/24006IPv6-only Tor2web has never actually connected to rend points over IPv62020-06-13T15:16:21ZteorIPv6-only Tor2web has never actually connected to rend points over IPv6This code should pass 1 to extend_info_from_node() when running Tor2web, and it should fall back to a 3-hop path if the node is NULL:
```
const node_t *node =
choose_good_exit_server(circ->base_.purpose, state->need_uptime,
...This code should pass 1 to extend_info_from_node() when running Tor2web, and it should fall back to a 3-hop path if the node is NULL:
```
const node_t *node =
choose_good_exit_server(circ->base_.purpose, state->need_uptime,
state->need_capacity, state->is_internal,
is_hs_v3_rp_circuit);
if (!node) {
log_warn(LD_CIRC,"Failed to choose an exit server");
return -1;
}
exit_ei = extend_info_from_node(node, 0);
if (BUG(exit_ei == NULL))
return -1;
```
I don't think we'll fix this, but I'm logging it for the record.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23975Make node_get_pref_ipv6_orport() check addresses in the right order2020-06-13T15:18:27ZteorMake node_get_pref_ipv6_orport() check addresses in the right ordernode_get_pref_ipv6_orport() and node_get_prim_orport() check addresses in the following order:
* routerinfo / descriptor (modified by rewrite_bridge_address_for_node())
* routerstatus / consensus
* microdesc
Clients, bridge clients, an...node_get_pref_ipv6_orport() and node_get_prim_orport() check addresses in the following order:
* routerinfo / descriptor (modified by rewrite_bridge_address_for_node())
* routerstatus / consensus
* microdesc
Clients, bridge clients, and relays usually get the correct address from node_get_pref_ipv6_orport() and node_get_prim_orport(), whether they are using microdescriptors or not.
But there are a few cases when this breaks:
* bridge clients should only check routerinfo for configured bridges
* all clients and relays that use microdescs should never check full descriptors (and vice versa, except for the bridge case)
* all clients and relays that use full descriptors should ignore the IPv6 address in the descriptor
* all clients and relays that use microdescriptors should ignore the IPv6 address in the microdescriptor, when using a consensus method that puts IPv6 addresses in the microdesc consensus, otherwise they should use the microdescriptorTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23470Avoid relays resolving their own address on every download status check2020-06-13T15:13:31ZteorAvoid relays resolving their own address on every download status checkMy branch 21789-mitigate has a fix that avoids relays doing useless resolves every time they check a download status. (And clients never do those resolves, because they're clients.)My branch 21789-mitigate has a fix that avoids relays doing useless resolves every time they check a download status. (And clients never do those resolves, because they're clients.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23415sample_laplace_distribution() should take multiple random inputs2020-06-13T15:13:20Zteorsample_laplace_distribution() should take multiple random inputsCurrently, sample_laplace_distribution() takes a random double as input, and then extracts the following random values:
* a random sign
* a random value in (0.0, 1.0]
This reduces the precision of the result. For details, see:
https://t...Currently, sample_laplace_distribution() takes a random double as input, and then extracts the following random values:
* a random sign
* a random value in (0.0, 1.0]
This reduces the precision of the result. For details, see:
https://trac.torproject.org/projects/tor/ticket/23061#comment:32
Instead, the function could take a random boolean sign and p, and the transform becomes:
```
result = mu - b * (sign ? 1.0 : -1.0)
* tor_mathlog(1.0 - p);
```
This would increase the precision by one bit, plus whatever precision is lost in `2.0 * fabs(p - 0.5)`.
This may have been introduced in dad5eb7.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22760Fix extra-info flags on fallbacks2020-06-13T15:10:54ZteorFix extra-info flags on fallbacksSee the first comment for details.See the first comment for details.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21720Update Directory Server Options section for automatic DirCache2020-06-13T15:07:17ZteorUpdate Directory Server Options section for automatic DirCacheThis section header is wrong:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers (that is,
if DirPort is non-zero):
```
It should read:
```
DIRECTORY SERVER OPTIONS
The followin...This section header is wrong:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers (that is,
if DirPort is non-zero):
```
It should read:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers:
(Relays with enough bandwidth automatically become directory
servers, see DirCache for details.)
```Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21506Client with current microdesc consensus but no descriptors chooses down fallb...2020-06-13T15:06:30ZteorClient with current microdesc consensus but no descriptors chooses down fallback every timeTor 0.2.9.9 doesn't have the fix for a similar issue in #20996, but 0.3.0.2-alpha does.
But this issue is different from that issue: the client downloads the consensus, then tries the same fallback (a down fallback) every time.
This re...Tor 0.2.9.9 doesn't have the fix for a similar issue in #20996, but 0.3.0.2-alpha does.
But this issue is different from that issue: the client downloads the consensus, then tries the same fallback (a down fallback) every time.
This really shouldn't happen: the client should choose a different relay every time.
My guess is that this relay is chosen because it's down, and all the up relay descriptors are unavailable. This is pathological behaviour.
I think we fixed it in 0.3.0.2-alpha with the patch to #20996, but I'm logging this bug just in case.
http://pastebin.ca/3769463Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20945Avoid an error in the fallback script when a fallback doesn't have any uptime2020-06-13T16:05:58ZteorAvoid an error in the fallback script when a fallback doesn't have any uptimeSometimes, the fallback generation script doesn't add attributes to the
fallbacks in the list. If this happens, log an error, and avoid selecting
that fallback.
Solution in #18828.Sometimes, the fallback generation script doesn't add attributes to the
fallbacks in the list. If this happens, log an error, and avoid selecting
that fallback.
Solution in #18828.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/20887DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead2020-06-13T15:04:02ZteorDIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d insteadA FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this ...A FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this functionality by setting the DirCache option to 0
```
So we should print the macro value the same way we do every other value, using "%d" in the string, and passing it as an argument.
(This macro changed name in #20684.)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20684DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM2020-06-13T15:03:27ZteorDIRCACHE_MIN_MB_BANDWIDTH is actually used for RAMWe should change DIRCACHE_MIN_BANDWIDTH and DIRCACHE_MIN_MB_BANDWIDTH to end in *_MEM, as they are only ever used for memory, not bandwidth.
Introduced in commit 997f779 in tor-0.2.8.1-alpha.We should change DIRCACHE_MIN_BANDWIDTH and DIRCACHE_MIN_MB_BANDWIDTH to end in *_MEM, as they are only ever used for memory, not bandwidth.
Introduced in commit 997f779 in tor-0.2.8.1-alpha.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20634Unit test address/get_if_addrs6_list_no_internal should succeed if there are ...2020-06-13T15:03:16ZteorUnit test address/get_if_addrs6_list_no_internal should succeed if there are only internal addressesSplit off #19960:
It is ok for the log message generated by address/get_if_addrs6_list_no_internal to be either:
* "connect() failed", or
* "unable to create socket", or
* "Address that we determined via UDP socket magic is unsuitable f...Split off #19960:
It is ok for the log message generated by address/get_if_addrs6_list_no_internal to be either:
* "connect() failed", or
* "unable to create socket", or
* "Address that we determined via UDP socket magic is unsuitable for public comms."
But we don't currently allow the third option.
```
address/get_if_addrs6_list_no_internal: [forking]
FAIL src/test/test_address.c:850: expected log to contain "connect() failed" o
r "unable to create socket" Captured logs:
1. err: "Address that we determined via UDP socket magic is unsuitable for p
ublic comms.\n"
[get_if_addrs6_list_no_internal FAILED]
```Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20591Ensure relays don't make multiple connections during bootstrap2020-06-13T15:03:03ZteorEnsure relays don't make multiple connections during bootstrapIn update_consensus_networkstatus_downloads, relays use `ClientBootstrapConsensusMaxInProgressTries` as the maximum number of in-progress attempts, even though this value should only be used for clients.
(However, relays do not delibera...In update_consensus_networkstatus_downloads, relays use `ClientBootstrapConsensusMaxInProgressTries` as the maximum number of in-progress attempts, even though this value should only be used for clients.
(However, relays do not deliberately launch multiple attempts, so the impact of this bug should be minimal. Still, we should fix this to defend against bugs like #20499.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20587Limit next_attempt_overflow to TIME_MAX, not INT_MAX2020-06-13T15:03:02ZNick MathewsonLimit next_attempt_overflow to TIME_MAX, not INT_MAXFound while examining #20499 codeFound while examining #20499 codeTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20307[warn] Remote server sent bogus reason code 650212020-06-13T15:01:58ZRoger Dingledine[warn] Remote server sent bogus reason code 65021On my Tor client running 0.2.9.3-alpha-dev (git-bfaded9143d127cb) on a really crummy network, I got a string of 65 of these lines:
```
Oct 06 16:21:58.020 [warn] Remote server sent bogus reason code 65021
Oct 06 16:21:59.027 [warn] Remot...On my Tor client running 0.2.9.3-alpha-dev (git-bfaded9143d127cb) on a really crummy network, I got a string of 65 of these lines:
```
Oct 06 16:21:58.020 [warn] Remote server sent bogus reason code 65021
Oct 06 16:21:59.027 [warn] Remote server sent bogus reason code 65021
...
```
In fact, I got one of those warns per second for 65 seconds.
But when I look at the more detailed logs for the first one, I see
```
Oct 06 16:21:58.020 [info] circuit_build_failed(): Our circuit failed to get a response from the first hop (62.210.123.24:443). I'm going to try to rotate to a better connection.
Oct 06 16:21:58.020 [info] entry_guard_register_connect_status(): Unable to connect to entry guard 'Alastor' (2EB3C230180694A1E848001E20F36F76A2287039). Marking as unreachable.
Oct 06 16:21:58.020 [warn] Remote server sent bogus reason code 65021
Oct 06 16:21:58.020 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x7fda41028de0 for circ_id 3884794536, channel ID 1 (0x7fda41c62410)
Oct 06 16:21:58.020 [debug] circuitmux_append_destroy_cell(): Cmux at 0x7fda41c625d0 queued a destroy for circ 3884794536, cmux counter is now 1, global counter is now 1
Oct 06 16:21:58.020 [debug] channel_send_destroy(): Sending destroy (circID 3884794536) on channel 0x7fda41c62410 (global ID 1)
```
So it would seem that no "end" cell was received at all. Maybe we are setting END_CIRC_REASON_FLAG_REMOTE somewhere where we shouldn't? Also, what is the mechanism by which the number makes it all the way up to 65021?Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20194Add "update fallbacks" to "Preliminaries" in Tor's doc/HACKING/ReleasingTor.md2020-06-13T15:01:37ZteorAdd "update fallbacks" to "Preliminaries" in Tor's doc/HACKING/ReleasingTor.mdWhen we added fallback directory mirrors, we should have also listed them as something we need to update every major release:
2. Early in the alpha series for each new major release, at least a month before the code freeze, update th...When we added fallback directory mirrors, we should have also listed them as something we need to update every major release:
2. Early in the alpha series for each new major release, at least a month before the code freeze, update the list of fallback directory mirrors using the instructions in: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrorsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20177When checking existing fallbacks, report those fallbacks at warning log level2020-06-13T16:05:46ZteorWhen checking existing fallbacks, report those fallbacks at warning log levelWhen the fallback script excludes some relays, it only logs at info level. This is usually what we want, but when checking existing fallbacks, it would be great to see any message about those fallbacks at WARNING log level.
This would m...When the fallback script excludes some relays, it only logs at info level. This is usually what we want, but when checking existing fallbacks, it would be great to see any message about those fallbacks at WARNING log level.
This would make it easier to work out why fallbacks are broken.Tor: unspecifiedhaxxpophaxxpop