Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:46Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34400control: HSFETCH command fails to validate v2 addresses2020-06-13T15:53:46ZDavid Gouletdgoulet@torproject.orgcontrol: HSFETCH command fails to validate v2 addressesIn `handle_control_hsfetch()`:
```
} else if (strcmpstart(arg1, v2_str) == 0 &&
rend_valid_descriptor_id(arg1 + v2_str_len) &&
base32_decode(digest, sizeof(digest), arg1 + v2_str_len,
...In `handle_control_hsfetch()`:
```
} else if (strcmpstart(arg1, v2_str) == 0 &&
rend_valid_descriptor_id(arg1 + v2_str_len) &&
base32_decode(digest, sizeof(digest), arg1 + v2_str_len,
REND_DESC_ID_V2_LEN_BASE32) ==
REND_DESC_ID_V2_LEN_BASE32) {
```
The above snippet is how we validate the v2 address for the `HSFETCH` command. The `base32_decode()` function returns the number of bytes _decoded_ and thus it should returns on success `sizeof(digest)`, not the total length of the base32 address (20 vs 32).
Issue was introduced in commit `a517daa56f5848d25ba79617a1a7b82ed2b0a7c0` meaning since 0.4.1.1-alpha (ticket #28913).
I noticed this because I recently updated the bad HSDirscanner Tor to use our latest and it broke the scanner.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34382Don't require M_SYSCALL in sandbox.c2020-06-13T15:53:45ZNick MathewsonDon't require M_SYSCALL in sandbox.cIn sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we ...In sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we don't have it defined can still build with m_syscall.
See also #32904 and #30987Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34298Address networkx's API change, which breaks OnionPerf2020-06-13T18:04:42ZPhilipp Winterphw@torproject.orgAddress networkx's API change, which breaks OnionPerfNetworkx in version [2.4](https://networkx.github.io/documentation/stable/release/release_2.4.html) deprecated the `node` attribute of `DiGraph` and suggests using `nodes` instead. This breaks OnionPerf but luckily, it's an easy fix.
He...Networkx in version [2.4](https://networkx.github.io/documentation/stable/release/release_2.4.html) deprecated the `node` attribute of `DiGraph` and suggests using `nodes` instead. This breaks OnionPerf but luckily, it's an easy fix.
Here's the error I'm getting on master:
```
Traceback (most recent call last):
File "/home/phw/rcs/onionperf/venv/bin/onionperf", line 4, in <module>
__import__('pkg_resources').run_script('OnionPerf==0.2rc0', 'onionperf')
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/pkg_resources/__init__.py", line 666, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/pkg_resources/__init__.py", line 1453, in run_script
exec(script_code, namespace, namespace)
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/EGG-INFO/scripts/onionperf", line 529, in <module>
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/EGG-INFO/scripts/onionperf", line 350, in main
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/EGG-INFO/scripts/onionperf", line 401, in measure
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/measurement.py", line 239, in run
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/measurement.py", line 315, in __start_tgen_client
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/measurement.py", line 341, in __start_tgen
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/model.py", line 66, in __init__
File "/home/phw/rcs/onionperf/venv/lib/python3.7/site-packages/OnionPerf-0.2rc0-py3.7.egg/onionperf/model.py", line 74, in generate
AttributeError: 'DiGraph' object has no attribute 'node'
```Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34246Add a link to the formatted architecture docs in src/mainpage.md2020-06-13T15:53:37ZteorAdd a link to the formatted architecture docs in src/mainpage.mdWhen I open up src/mainpage.md. it's obviously meant to be formatted by a markdown parser. (And GitHub's markdown doesn't seem to handle "@" directives.)
Can you add a link to the formatted output at the top of mainpage.md ?When I open up src/mainpage.md. it's obviously meant to be formatted by a markdown parser. (And GitHub's markdown doesn't seem to handle "@" directives.)
Can you add a link to the formatted output at the top of mainpage.md ?Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34013Bump node version to v10.21.02020-06-16T01:26:20ZGeorg KoppenBump node version to v10.21.0Update our node version to what is used in mozilla-central.Update our node version to what is used in mozilla-central.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/33933Bandwidth distribution graph has "0 Gbit/s" for all y axis labels2020-06-13T18:15:34ZRoger DingledineBandwidth distribution graph has "0 Gbit/s" for all y axis labelsSee e.g. https://metrics.torproject.org/advbwdist-perc.html?start=2015-01-19&end=2020-04-18&p=50
This is likely the same type of rounding bug as #33066.
(I wonder if there are other graphs that have this issue, too?)See e.g. https://metrics.torproject.org/advbwdist-perc.html?start=2015-01-19&end=2020-04-18&p=50
This is likely the same type of rounding bug as #33066.
(I wonder if there are other graphs that have this issue, too?)https://gitlab.torproject.org/legacy/trac/-/issues/33918Stop truncating IPv6 addresses in channel logs2020-06-13T15:53:10ZteorStop truncating IPv6 addresses in channel logschannel_tls_get_remote_desc_method() formats IP addresses and ports, but its buffer is only 32 characters. IPv6 addresses can be up to 41 characters long, and the port is an extra 6 characters.channel_tls_get_remote_desc_method() formats IP addresses and ports, but its buffer is only 32 characters. IPv6 addresses can be up to 41 characters long, and the port is an extra 6 characters.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33873client: Send back SOCKS extended error F6 in case of bad hostname2020-06-13T15:53:01ZDavid Gouletdgoulet@torproject.orgclient: Send back SOCKS extended error F6 in case of bad hostnameWith the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoie...With the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoieqw.onion`.
Problem is that we only send back the `F6` code if the address was identified, by length, as a v3. We should handle the `BAD_HOSTNAME` error code from `parse_extended_hostname()` and thus send back that extended error.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33804Defer "PreferIPv6 by default" to 0.4.42020-06-13T15:52:47ZteorDefer "PreferIPv6 by default" to 0.4.4In #32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in #33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-onl...In #32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in #33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-only resolves for torsocks.
Since #32637, we have also merged:
* #33608, which removes a forced PreferIPv6 for non-SOCKSPorts
* #32994, which puts the PreferIPv6 default in port_parse_config(), rather than in 2 different places in the code
So it should be very easy to change the default for PreferIPv6.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/33780hs-v3: Change to log notice the registration of an OB instance2020-06-13T15:52:42ZDavid Gouletdgoulet@torproject.orghs-v3: Change to log notice the registration of an OB instanceChange this info to notice:
```
Mar 29 15:59:12.000 [info] ob_option_parse(): OnionBalance: MasterOnionAddress *******.onion registered
```Change this info to notice:
```
Mar 29 15:59:12.000 [info] ob_option_parse(): OnionBalance: MasterOnionAddress *******.onion registered
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33678Disable practracker in git hooks in maint-0.4.32020-06-13T15:52:27ZteorDisable practracker in git hooks in maint-0.4.3Let's remove .enable_practracker_in_hooks to disable practracker in hooks in maint-0.4.3.Let's remove .enable_practracker_in_hooks to disable practracker in hooks in maint-0.4.3.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33673Use the right DLLs and pkg-config path on Appveyor2020-06-13T15:52:26ZteorUse the right DLLs and pkg-config path on AppveyorWe want to future-proof our Appveyor CI against dll and pkg-config issues.
Split off from #33643, which is the urgent CI fix.We want to future-proof our Appveyor CI against dll and pkg-config issues.
Split off from #33643, which is the urgent CI fix.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33646Wrong list of enabled modules2020-06-13T15:52:22ZTracWrong list of enabled modulesWhen I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth...When I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth (--disable-module-dirauth): yes
dircache (--disable-module-dircache): yes
```
Which is wrong, since I have enabled relay and disabled dirauth.
Looks like problem is located in commit [9c33d36113447d38decd22d177e62fb225826d78](https://gitweb.torproject.org/tor.git/commit/?id=9c33d36113447d38decd22d177e62fb225826d78).
Related: #32230.
Please recheck.
**Trac**:
**Username**: VortTor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33642Add *.a to .gitignore2020-06-13T15:52:20ZDavid Gouletdgoulet@torproject.orgAdd *.a to .gitignoreMade a mistake to add a .a file while switching from 043 and master into a branch.
I think adding `*.a` to .gitignore should be a reasonable idea since these files are always generated in our build system.Made a mistake to add a .a file while switching from 043 and master into a branch.
I think adding `*.a` to .gitignore should be a reasonable idea since these files are always generated in our build system.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33641Spurious coverity unreachable warning after all bugs are fatal test skip2020-06-13T15:52:19ZteorSpurious coverity unreachable warning after all bugs are fatal test skipThere's a spurious coverity warning about unreachable code, in tests that we're skipping when ALL_BUGS_ARE_FATAL is defined.
I guess we need to wrap those skips in `#ifndef COVERITY`.
```
** CID 1460753: Control flow issues (UNREACHA...There's a spurious coverity warning about unreachable code, in tests that we're skipping when ALL_BUGS_ARE_FATAL is defined.
I guess we need to wrap those skips in `#ifndef COVERITY`.
```
** CID 1460753: Control flow issues (UNREACHABLE)
/src/test/test_dir.c: 4998 in test_dir_purpose_needs_anonymity_returns_true_by_default()
________________________________________________________________________________________________________
*** CID 1460753: Control flow issues (UNREACHABLE)
/src/test/test_dir.c: 4998 in test_dir_purpose_needs_anonymity_returns_true_by_default()
4992 (void)arg;
4993
4994 #ifdef ALL_BUGS_ARE_FATAL
4995 tt_skip();
4996 #endif
4997
CID 1460753: Control flow issues (UNREACHABLE)
This code cannot be reached: "tor_capture_bugs_(1);".
4998 tor_capture_bugs_(1);
4999 setup_full_capture_of_logs(LOG_WARN);
5000 tt_int_op(1, OP_EQ, purpose_needs_anonymity(0, 0, NULL));
5001 tt_int_op(1, OP_EQ, smartlist_len(tor_get_captured_bug_log_()));
5002 expect_single_log_msg_containing("Called with dir_purpose=0");
5003
** CID 1460752: Control flow issues (UNREACHABLE)
/src/test/test_circuitbuild.c: 123 in test_new_route_len_unhandled_exit()
________________________________________________________________________________________________________
*** CID 1460752: Control flow issues (UNREACHABLE)
/src/test/test_circuitbuild.c: 123 in test_new_route_len_unhandled_exit()
117 #ifdef ALL_BUGS_ARE_FATAL
118 tt_skip();
119 #endif
120
121 MOCK(count_acceptable_nodes, mock_count_acceptable_nodes);
122
CID 1460752: Control flow issues (UNREACHABLE)
This code cannot be reached: "tor_capture_bugs_(1);".
123 tor_capture_bugs_(1);
124 setup_full_capture_of_logs(LOG_WARN);
125 r = new_route_len(CIRCUIT_PURPOSE_CONTROLLER, &dummy_ei, &dummy_nodes);
126 tt_int_op(DEFAULT_ROUTE_LEN + 1, OP_EQ, r);
127 tt_int_op(smartlist_len(tor_get_captured_bug_log_()), OP_EQ, 1);
128 tt_str_op(smartlist_get(tor_get_captured_bug_log_(), 0), OP_EQ,
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33635Regenerate practracker exceptions in master2020-06-13T15:52:18ZteorRegenerate practracker exceptions in masterEvery so often, we do a full regenerate of the practracker exceptions file.
A full regenerate accepts the current state of the tor codebase, and clears the list of practracker warnings.
That way, reviewers can focus on new warnings. (A...Every so often, we do a full regenerate of the practracker exceptions file.
A full regenerate accepts the current state of the tor codebase, and clears the list of practracker warnings.
That way, reviewers can focus on new warnings. (And we aren't confusing new users.)
Ideally, we should slowly be removing files and functions from the exceptions file, as we resolve technical debt.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33623sendme: Change default emit cell version from 0 to 12020-06-13T15:52:14ZDavid Gouletdgoulet@torproject.orgsendme: Change default emit cell version from 0 to 1In #32774, the consensus is telling every relay to emit SENDME v1.
We should change the default hardcoded value from 0 to 1 as well.In #32774, the consensus is telling every relay to emit SENDME v1.
We should change the default hardcoded value from 0 to 1 as well.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33608Stop forcing prefer IPv6 on non-SOCKSPorts2020-06-13T15:52:11ZteorStop forcing prefer IPv6 on non-SOCKSPortsIn #32637 we forced PreferIPv6 on all non-SOCKSPorts.
That could be a breaking change for some users, and they will have no way to recover. We should just set a sensible default, and let users tweak it if it doesn't work for them.In #32637 we forced PreferIPv6 on all non-SOCKSPorts.
That could be a breaking change for some users, and they will have no way to recover. We should just set a sensible default, and let users tweak it if it doesn't work for them.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33607Stop forcing IPv4 and IPv6 traffic on non-SOCKSPorts2020-06-13T15:52:10ZteorStop forcing IPv4 and IPv6 traffic on non-SOCKSPortsAfter #32994, the defaults in `port_cfg_new()` will apply to all parsed ports. (Not just default ports.)
I am not sure what we should do with the extra settings in `connection_listener_new()`:
```
if (type != CONN_TYPE_AP_LISTENER) {
...After #32994, the defaults in `port_cfg_new()` will apply to all parsed ports. (Not just default ports.)
I am not sure what we should do with the extra settings in `connection_listener_new()`:
```
if (type != CONN_TYPE_AP_LISTENER) {
lis_conn->entry_cfg.ipv4_traffic = 1;
lis_conn->entry_cfg.ipv6_traffic = 1;
lis_conn->entry_cfg.prefer_ipv6 = 1;
}
```
Here are our options:
* leave them there: non-SOCKSPorts will always have IPv4, IPv6, and prefer IPv6 traffic
* copy the defaults from port_cfg_new(): non-SOCKSPorts will always have DNS, Onion, and prefer IPv6 virtual addresses. Forcing these options on might make some configs break.
* delete them: non-SOCKSPorts can now disable IPv4, IPv6, and prefer IPv4 traffic. Some rare configs might break, because they relied on the options being forced on.
Here's what I think we should do long-term:
* set reasonable defaults (in #32994)
* stop forcing options on (this ticket)
* warn users that some rare configs might break, and they should remove NoIPv4Traffic or NoIPv6Traffic as needed (this changes file)
"prefer IPv6 traffic" was added in #32637 in 0.4.3.1-alpha. We don't want to force that option on in 0.4.3, that makes the problem worse, and might break some existing configs. See #33608 for a fix.Tor: 0.4.5.x-final