Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:58:19Zhttps://gitlab.torproject.org/legacy/trac/-/issues/19298Have tor-guts describe containers2020-06-13T14:58:19ZNick MathewsonHave tor-guts describe containersTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19296Have tor-guts cover time-related util functions2020-06-13T14:58:18ZNick MathewsonHave tor-guts cover time-related util functionsTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19203node_get_by_nickname() fails to give warning on unique-but-unnamed node.2020-06-13T14:58:04ZNick Mathewsonnode_get_by_nickname() fails to give warning on unique-but-unnamed node.There are two checks in node_get_by_nickname for listing an unnamed router by name. One checks for `(smartlist_len(matches)>1 && warn_if_unnamed)`, whereas the other one also checks for `(smartlist_len(matches)>1 && warn_if_unnamed)`. ...There are two checks in node_get_by_nickname for listing an unnamed router by name. One checks for `(smartlist_len(matches)>1 && warn_if_unnamed)`, whereas the other one also checks for `(smartlist_len(matches)>1 && warn_if_unnamed)`. Whoops.
The impact is that if there is one match, no warning will be produced, even though it arguably should (now that Naming is no longer a thing).
Found by GCC6 with -Wduplicated-cond as part of #19180.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19079clang -m32 -ftrapv seems buggy with 64-bit signed integer multiply2020-06-13T14:57:32ZNick Mathewsonclang -m32 -ftrapv seems buggy with 64-bit signed integer multiplyIf you try building with clang -m32 -ftrapv, you get a bunch of these warnings:
```
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:828: undefined reference to `__mulodi4'
12:39:59 ...If you try building with clang -m32 -ftrapv, you get a bunch of these warnings:
```
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:828: undefined reference to `__mulodi4'
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:828: undefined reference to `__mulodi4'
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:855: undefined reference to `__mulodi4'
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:930: undefined reference to `__mulodi4'
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:930: undefined reference to `__mulodi4'
12:39:59 src/or/libtor-testing.a(src_or_libtor_testing_a-dirvote.o):/home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:834: more undefined references to `__mulodi4' follow
```
Since -ftrapv is now on by default, that's a problem!
Others have seen errors like this before; for example see:
https://bugs.chromium.org/p/chromium/issues/detail?id=503229
and
https://llvm.org/bugs/show_bug.cgi?id=14469
I'm calling this must-fix-for-029, since otherwise we just broke 32-bit clang.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18982Tor should log 1-based hop numbers2020-06-13T14:57:04ZteorTor should log 1-based hop numbersThe control-spec says hops are 1-based, and we often log "first hop":
```
If HOP=HopNum is specified, Tor will choose the HopNumth hop in the
circuit as the exit node, rather than the last node in the circuit.
Hops are 1-indexed; g...The control-spec says hops are 1-based, and we often log "first hop":
```
If HOP=HopNum is specified, Tor will choose the HopNumth hop in the
circuit as the exit node, rather than the last node in the circuit.
Hops are 1-indexed; generally, it is not permitted to attach to hop 1.
```
But the following functions log 0-based hops:
* choose_good_middle_server
* onion_extend_cpath (which also logs a 1-based hop message as well)
We need to add 1 to the 0-based hop counts in these functions.
Credit to Xiaofan Li for discovering this issue.Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/18357HiddenServicePort IPv6 broken2020-06-13T14:54:36ZTracHiddenServicePort IPv6 brokenHi,
In reference to: #6551 and #12670.
I was not having much luck setting up a Hidden Service. I found later that worked when I used 127.0.0.1:80 instead of [::1]:80.
I then tested v6 and v4, side-by-side:
HiddenServicePort 80 127.0.0...Hi,
In reference to: #6551 and #12670.
I was not having much luck setting up a Hidden Service. I found later that worked when I used 127.0.0.1:80 instead of [::1]:80.
I then tested v6 and v4, side-by-side:
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 81 [::1]:80
Port 80 worked, 81 did not. I checked a few times with curl locally and with tor browser.
I'm running FreeBSD 10.2. Had a pretty slim configuration when I tried this. Verified with fetch and sockstat that indeed the service was listening on ::1 (::0/0, actually).
Thank you,
Teran
**Trac**:
**Username**: sega01Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/13221Misleading error messages about bind_ipv4_only and bind_ipv6_only?2020-06-13T14:39:00ZRoger DingledineMisleading error messages about bind_ipv4_only and bind_ipv6_only?```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with t...```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with the one below it.Tor: 0.3.5.x-final