Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:42:21Zhttps://gitlab.torproject.org/legacy/trac/-/issues/30821Fix a typo in test_rebind.sh2020-06-13T15:42:21ZteorFix a typo in test_rebind.shTor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30261Add "How do I find bug or feature versions?" to doc/HACKING2020-06-13T15:40:55ZteorAdd "How do I find bug or feature versions?" to doc/HACKINGWe need to find bugfix versions for changes files and backports, and feature versions for specifications.
Let's document the git commands to do that.
For an example, see:
https://trac.torproject.org/projects/tor/ticket/30224#comment:4We need to find bugfix versions for changes files and backports, and feature versions for specifications.
Let's document the git commands to do that.
For an example, see:
https://trac.torproject.org/projects/tor/ticket/30224#comment:4Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30224Add the tor versions for bridge-distribution-request2020-06-13T15:40:52ZteorAdd the tor versions for bridge-distribution-requestdir-spec says it's not implemented, but it was implemented in 0.3.2.3-alpha and backported.
#18329 was Sponsor M, but the relevant current sponsor is Sponsor 19.dir-spec says it's not implemented, but it was implemented in 0.3.2.3-alpha and backported.
#18329 was Sponsor M, but the relevant current sponsor is Sponsor 19.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30119cert-spec uses binary encodings but does not specify byte order2020-06-13T15:40:35Zirlcert-spec uses binary encodings but does not specify byte orderFrom looking at the Tor implementation (in a black box way, didn't look at the source code) these seem to be big endian byte order. We should have a note in cert-spec for implementors so they don't have to guess.From looking at the Tor implementation (in a black box way, didn't look at the source code) these seem to be big endian byte order. We should have a note in cert-spec for implementors so they don't have to guess.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30114Also fetch tor-github when we git-pull-all.sh2020-06-13T15:40:33ZteorAlso fetch tor-github when we git-pull-all.shIf we don't automatically fetch tor-github, then someone will eventually merge an old version of a pull request.If we don't automatically fetch tor-github, then someone will eventually merge an old version of a pull request.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30001test failure: dir_handle_get/status_vote_next_bandwidth2020-06-13T15:40:12ZNick Mathewsontest failure: dir_handle_get/status_vote_next_bandwidthFound by travis: https://travis-ci.org/torproject/tor/jobs/515199996
```
dir_handle_get/status_vote_next_bandwidth:
FAIL src/test/test_dir_handle_get.c:2535: assert(strstr(header, expires))
[status_vote_next_bandwidth FAILED]
```
...Found by travis: https://travis-ci.org/torproject/tor/jobs/515199996
```
dir_handle_get/status_vote_next_bandwidth:
FAIL src/test/test_dir_handle_get.c:2535: assert(strstr(header, expires))
[status_vote_next_bandwidth FAILED]
```
To me this looks like a race condition: the clock probably has advanced by a second between the call to directory_handle_command_get() and the call to time(NULL).Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29961Update the Tor version for bandwidth-file-digest in torspec2020-06-13T15:40:01ZteorUpdate the Tor version for bandwidth-file-digest in torspecSee my pull request:
https://github.com/torproject/torspec/pull/73See my pull request:
https://github.com/torproject/torspec/pull/73Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29960Actually check for errors in digest256_to_base64() and callers2020-06-13T15:40:00ZteorActually check for errors in digest256_to_base64() and callersWe don't propagate errors from base64_encode() to digest256_to_base64() and its callers.
Discovered as part of #29959.We don't propagate errors from base64_encode() to digest256_to_base64() and its callers.
Discovered as part of #29959.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29959Actually include the bandwidth file digest in the vote2020-06-13T15:40:00ZteorActually include the bandwidth file digest in the voteThe original code in #26698 had a logic error, so the bandwidth file digest was never included in the vote.The original code in #26698 had a logic error, so the bandwidth file digest was never included in the vote.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29958Error: SIZEOF_UNSIGNED_INT is undefined2020-06-13T15:39:59ZteorError: SIZEOF_UNSIGNED_INT is undefined```
In file included from ../src/feature/control/control_getinfo.c:14:
In file included from ../src/core/or/or.h:16:
../src/lib/cc/torint.h:132:5: error: 'SIZEOF_UNSIGNED_INT' is not defined,
evaluates to 0 [-Werror,-Wundef]
#if SI...```
In file included from ../src/feature/control/control_getinfo.c:14:
In file included from ../src/core/or/or.h:16:
../src/lib/cc/torint.h:132:5: error: 'SIZEOF_UNSIGNED_INT' is not defined,
evaluates to 0 [-Werror,-Wundef]
#if SIZEOF_UNSIGNED_INT > SIZEOF_VOID_P
^
make: *** [src/feature/control/control_auth.o] Error 1
```Tor: 0.4.1.x-finalteorteorhttps://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/29826Rename router_status_t to avoid confusion with routerstatus_t2020-06-13T15:39:37ZteorRename router_status_t to avoid confusion with routerstatus_tTor has routerstatus_t in many files, and a router_status_t in process_descs.c.
That's terribly confusing, we should rename router_status_t.Tor has routerstatus_t in many files, and a router_status_t in process_descs.c.
That's terribly confusing, we should rename router_status_t.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29802Document the v3 onion service key files in the tor man page2020-06-13T15:39:28ZteorDocument the v3 onion service key files in the tor man pageThe tor man page is missing the names of the key files for v3 onion services.The tor man page is missing the names of the key files for v3 onion services.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29780Run travis with python2 and python32020-06-13T15:39:23ZteorRun travis with python2 and python3We should make sure all of tor's test python scripts run in environments where python3 is the default.
(Scripts are also allowed to explicitly require python3. But they can't depend on python2, because it is end of life on 1 Jan 2020.)
...We should make sure all of tor's test python scripts run in environments where python3 is the default.
(Scripts are also allowed to explicitly require python3. But they can't depend on python2, because it is end of life on 1 Jan 2020.)
We should be able to copy the python bits of our chutney travis config into Tor.
Let's just pick the newest python 3?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29777Rate-limit "Problem bootstrapping" warnings to one every 5 seconds2020-06-13T15:39:22ZteorRate-limit "Problem bootstrapping" warnings to one every 5 secondsLet's put a rate-limit on warnings like this:
```
Jan 29 11:36:27.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 11; recommendation warn; host 322C6E3A973BC10FC36DE3037AD27BC89...Let's put a rate-limit on warnings like this:
```
Jan 29 11:36:27.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 11; recommendation warn; host 322C6E3A973BC10FC36DE3037AD27BC89F14723B at 212.83.154.33:8443)
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29776Mark proposal 301 as "Accepted", and update the index2020-06-13T15:39:22ZteorMark proposal 301 as "Accepted", and update the indexTor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29689Make Tor's test-network.sh consistent with chutney's test-network.sh2020-06-13T15:39:03ZteorMake Tor's test-network.sh consistent with chutney's test-network.shIn #27067, we fixed some bugs in chutney's test-network.sh. But we forgot to copy those changes into tor's test-network.sh.
We should update tor's test-network.sh to fix these bugs, and be consistent with chutney. And we should add a no...In #27067, we fixed some bugs in chutney's test-network.sh. But we forgot to copy those changes into tor's test-network.sh.
We should update tor's test-network.sh to fix these bugs, and be consistent with chutney. And we should add a note on both sides to keep them in sync.
Edit: ticket numberTor: unspecifiedhttps://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/29617OOM manger wipes entire DNS cache2020-06-13T15:38:47ZpullsOOM manger wipes entire DNS cacheIn relay.c, function cell_queues_check_size, the OOM manager attempts to clear one tenth of MaxMemInQueues bytes from the DNS cache by calling dns_cache_handle_oom. The function dns_cache_handle_oom, in dns.c, runs in a loop removing cac...In relay.c, function cell_queues_check_size, the OOM manager attempts to clear one tenth of MaxMemInQueues bytes from the DNS cache by calling dns_cache_handle_oom. The function dns_cache_handle_oom, in dns.c, runs in a loop removing cached entries that are now+n*time_inc old, until at least the requested number of bytes have been freed. The first iteration of the loop has n=0, and likely will not remove enough bytes. The second iteration is way too aggressive, because:
```
time_inc += 3600; /* Increase time_inc by 1 hour. */
```
This is guaranteed to wipe the entire DNS cache, because in dns_clip_ttl the maximum time to cache is MAX_DNS_TTL_AT_EXIT, which is set in dns.h to:
```
/** Lowest value for DNS ttl that a server will give. */
#define MIN_DNS_TTL_AT_EXIT (5*60)
/** Highest value for DNS ttl that a server will give. */
#define MAX_DNS_TTL_AT_EXIT (60*60)
```
One possible and reasonable fix would be to instead increment time_inc by MIN_DNS_TTL_AT_EXIT.Tor: 0.3.5.x-finalNick MathewsonNick Mathewson