Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:36:15Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28989test_hs_service: CID 1442277: Resource leaks (RESOURCE_LEAK)2020-06-13T15:36:15ZGeorge Kadianakistest_hs_service: CID 1442277: Resource leaks (RESOURCE_LEAK)```
/src/test/test_hs_service.c: 1657 in test_build_descriptors()
1651 {
1652 hs_service_t *service = helper_create_service();
1653 service_descriptor_free(service->desc_current);
1654 service->desc_current ...```
/src/test/test_hs_service.c: 1657 in test_build_descriptors()
1651 {
1652 hs_service_t *service = helper_create_service();
1653 service_descriptor_free(service->desc_current);
1654 service->desc_current = NULL;
1655
1656 build_all_descriptors(now);
>>> CID 1442277: Resource leaks (RESOURCE_LEAK)
>>> Variable "service" going out of scope leaks the storage it points to.
1657 tt_assert(service->desc_current);
1658 tt_assert(service->desc_current->desc);
```Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/28976git pre-commit hook that runs 'make check-spaces' and 'make check-changes'2020-06-13T15:36:12Zrl1987git pre-commit hook that runs 'make check-spaces' and 'make check-changes'We already have scripts/maint/pre-push.git-hook which helps preventing fixup commits from ending up in upstream branches. We should also have a pre-commit hook script to prevent creating commits that would fail whitespace and change file...We already have scripts/maint/pre-push.git-hook which helps preventing fixup commits from ending up in upstream branches. We should also have a pre-commit hook script to prevent creating commits that would fail whitespace and change file checkers.Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/28757Remove deprecated ControlPort commands from GETINFO info/names listing2020-06-13T15:35:19ZTracRemove deprecated ControlPort commands from GETINFO info/names listingIf `GETINFO` commands `status/version/num-concurring` and `status/version/num-versioning` are used in Nyx or `tor-prompt`, Tor writes to its log file:
```
[warn] status/version/num-concurring is deprecated; it no longer gives useful inf...If `GETINFO` commands `status/version/num-concurring` and `status/version/num-versioning` are used in Nyx or `tor-prompt`, Tor writes to its log file:
```
[warn] status/version/num-concurring is deprecated; it no longer gives useful information
[warn] status/version/num-versioning is deprecated; it no longer gives useful information
```
These commands should be removed from interpreter's `/help GETINFO` listing. They are deprecated according to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|control-spec.txt]]:
```
"status/version/num-concurring"
"status/version/num-versioning"
These options are deprecated; they no longer give useful information.
```
[[0.2.0.30](https://blog.torproject.org/tor-02030-released-stable|since)] (more than 10 years):
> o Newly deprecated features:
> - The `status/version/num-versioning` and `status/version/num-concurring` `GETINFO` controller options are no longer useful in the v3 directory protocol: treat them as deprecated, and warn when they're used.
Probably, there are also other deprecated commands in `/help` listing. They should be removed too.
P.S. Initially it was reported in [[comment](https://trac.torproject.org/projects/tor/ticket/28300#comment:4|this)]. teor [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28676#comment:8|recommended]] to create separate ticket.
**Trac**:
**Username**: wagonTor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/28560hs: Mention in the manpage that Sandbox and adding a service with the control...2020-06-13T15:34:26ZDavid Gouletdgoulet@torproject.orghs: Mention in the manpage that Sandbox and adding a service with the control port failsFrom #16106.
We can't tell the sandbox about a new `HiddenServiceDir` at runtime so this will always fail until we get a better sandbox system.
For now, we should at least document it in the manpage.From #16106.
We can't tell the sandbox about a new `HiddenServiceDir` at runtime so this will always fail until we get a better sandbox system.
For now, we should at least document it in the manpage.Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/28058Run shellcheck as part of "make check"2020-06-13T15:40:56ZteorRun shellcheck as part of "make check"To avoid introducing shell script issues into Tor, we could run shellcheck (https://github.com/koalaman/shellcheck) as part of "make check".
Since this is a technical debt check, I am tentatively assigning it to 0.3.6.To avoid introducing shell script issues into Tor, we could run shellcheck (https://github.com/koalaman/shellcheck) as part of "make check".
Since this is a technical debt check, I am tentatively assigning it to 0.3.6.Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/28011shellcheck: run_calltool.sh issues2020-06-13T15:32:44Zrl1987shellcheck: run_calltool.sh issuesShellcheck (https://github.com/koalaman/shellcheck) finds the following issues:
```
In run_calltool.sh line 18:
python -m calltool $calculation > callgraph/$calculation
^-- SC2086: Double quote to prevent glo...Shellcheck (https://github.com/koalaman/shellcheck) finds the following issues:
```
In run_calltool.sh line 18:
python -m calltool $calculation > callgraph/$calculation
^-- SC2086: Double quote to prevent globbing and word splitting.
^-- SC2086: Double quote to prevent globbing and word splitting.
In run_calltool.sh line 21:
echo <<EOF > callgraph/README
^-- SC2217: Redirecting to 'echo', a command that doesn't read stdin. Bad quoting or missing xargs?
```Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/28010shellcheck: run_trunnel.sh issues2020-06-13T15:32:44Zrl1987shellcheck: run_trunnel.sh issuesShellcheck (https://github.com/koalaman/shellcheck) finds the following issues:
```
In run_trunnel.sh line 12:
for file in `find ./src/trunnel/ -name '*.trunnel'`; do
^-- SC2044: For loops over find output are fragile. ...Shellcheck (https://github.com/koalaman/shellcheck) finds the following issues:
```
In run_trunnel.sh line 12:
for file in `find ./src/trunnel/ -name '*.trunnel'`; do
^-- SC2044: For loops over find output are fragile. Use find -exec or a while read loop.
^-- SC2006: Use $(..) instead of legacy `..`.
In run_trunnel.sh line 13:
python -m trunnel ${OPTIONS} $file
^-- SC2086: Double quote to prevent globbing and word splitting.
```Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/27993craft a git pre push hook that declines to receive fixup! commits?2020-06-13T15:32:36ZRoger Dingledinecraft a git pre push hook that declines to receive fixup! commits?Every so often I see nickm push a commit to tor's main git that is a fixup! commit. It's clear that he meant to squash them before the push but didn't.
Is there some one-liner or something we can put in a git hook that notices these uni...Every so often I see nickm push a commit to tor's main git that is a fixup! commit. It's clear that he meant to squash them before the push but didn't.
Is there some one-liner or something we can put in a git hook that notices these unintended commits and tells us to fix them before pushing?Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/27625add unit tests for tokenize_string() and get_next_token()2020-06-13T15:33:12ZTracadd unit tests for tokenize_string() and get_next_token()It looks like there aren't any.
**Trac**:
**Username**: cyberpunksIt looks like there aren't any.
**Trac**:
**Username**: cyberpunksTor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/27620Use trunnel to parse and generate SOCKS wire format in tor-resolve2020-06-13T15:31:05Zrl1987Use trunnel to parse and generate SOCKS wire format in tor-resolveTor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/27325Rework NETINFO cell parsing and generation with trunnel2020-06-13T15:30:13Zrl1987Rework NETINFO cell parsing and generation with trunnelIn `channel_tls_process_netinfo_cell()` we have:
```
1720 /* Decode the cell. */
1721 timestamp = ntohl(get_uint32(cell->payload));
1722 if (labs(now - chan->conn->handshake_state->sent_versions_at) < 180) {
1723 apparent_skew...In `channel_tls_process_netinfo_cell()` we have:
```
1720 /* Decode the cell. */
1721 timestamp = ntohl(get_uint32(cell->payload));
1722 if (labs(now - chan->conn->handshake_state->sent_versions_at) < 180) {
1723 apparent_skew = now - timestamp;
1724 }
1725
1726 my_addr_type = (uint8_t) cell->payload[4];
1727 my_addr_len = (uint8_t) cell->payload[5];
1728 my_addr_ptr = (uint8_t*) cell->payload + 6;
1729 end = cell->payload + CELL_PAYLOAD_SIZE;
1730 cp = cell->payload + 6 + my_addr_len;
```
and in `connection_or_send_netinfo()` we write the cell to connection buffer. Trunnel should be used.Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/23082tor_addr_parse is overly permissive2020-06-13T15:42:01ZDavid Fifielddcf@torproject.orgtor_addr_parse is overly permissivetor_addr_parse allows these surprising address formats:
* `[192.0.2.1]` (IPv4 in square brackets) → 192.0.2.1
* `[11.22.33.44` (IPv4 with left square bracket only) → 11.22.33.4
* `[11:22::33:44` (IPv6 with left square bracket only) → ...tor_addr_parse allows these surprising address formats:
* `[192.0.2.1]` (IPv4 in square brackets) → 192.0.2.1
* `[11.22.33.44` (IPv4 with left square bracket only) → 11.22.33.4
* `[11:22::33:44` (IPv6 with left square bracket only) → 11:22::33:4
* `11:22::33:44:` (IPv6 with trailing colon) → 11:22::33:44Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/21900evdns fails when resolv.conf is missing, but succeeds when resolv.conf is empty2020-06-13T15:07:44Zteorevdns fails when resolv.conf is missing, but succeeds when resolv.conf is emptyWhen tor's ServerDNSResolvConfFile (default /etc/resolv.conf) is missing, evdns does not add any name servers, and therefore Exits do not allow any exit traffic (not even IP-based traffic):
```
[debug] configure_nameservers: stat()ing /e...When tor's ServerDNSResolvConfFile (default /etc/resolv.conf) is missing, evdns does not add any name servers, and therefore Exits do not allow any exit traffic (not even IP-based traffic):
```
[debug] configure_nameservers: stat()ing /etc/resolv.conf
[warn] Unable to stat resolver configuration in '/etc/resolv.conf': No such file or directory
[info] mark_my_descriptor_dirty: Decided to publish new relay descriptor: dns resolvers failed
```
This happens on macOS when the network is down. On macOS, /etc/resolv.conf is symlinked to /var/run/resolv.conf. When the network is down, macOS deletes /var/run/resolv.conf, so the stat() call on /etc/resolv.conf fails.
But when tor's ServerDNSResolvConfFile is empty, evdns adds a default name server (127.0.0.1:53 on my macOS), and therefore Exits allow exit traffic:
```
[info] eventdns: Parsing resolv.conf file /dev/null
[info] eventdns: Added nameserver 127.0.0.1:53 as 0x615000009e00
[info] mark_my_descriptor_dirty: Decided to publish new relay descriptor: dns resolvers failed
[info] eventdns: Parsing resolv.conf file /dev/null
...
[info] mark_my_descriptor_dirty: Decided to publish new relay descriptor: dns resolvers back
```
We should also stop the extra descriptor upload:
```
[info] mark_my_descriptor_dirty: Decided to publish new relay descriptor: dns resolvers failed
```Tor: 0.4.0.x-finalrl1987rl1987