Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:39:59Zhttps://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/29913Stop assuming that /usr/bin/python3 exists2020-06-13T15:50:45ZteorStop assuming that /usr/bin/python3 existspython3 is in /usr/local/bin on my system, so I see:
```
$ scripts/maint/practracker/practracker.py
-bash: scripts/maint/practracker/practracker.py: /usr/bin/python3: bad interpreter: No such file or directory
```python3 is in /usr/local/bin on my system, so I see:
```
$ scripts/maint/practracker/practracker.py
-bash: scripts/maint/practracker/practracker.py: /usr/bin/python3: bad interpreter: No such file or directory
```Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29879Make git-push-all.sh push branches in a specific order2020-06-13T15:44:38ZteorMake git-push-all.sh push branches in a specific ordergit-push-all.sh currently pushes all the branches at once. Then GitHub sends requests to build each branch to Travis and Appveyor.
Depending on the exact order of the push and network requests, branches are built in an arbitrary order.
...git-push-all.sh currently pushes all the branches at once. Then GitHub sends requests to build each branch to Travis and Appveyor.
Depending on the exact order of the push and network requests, branches are built in an arbitrary order.
Ideally, we want to push branches in this order:
* master
* practracker errors
* errors that appear when merging backports to a later release
* maint branches, in order from the earliest release, to the most recent release
* errors that appear when merging the PR into code that was added after the PR merge was build
* release branches, in the same order
So we should push branches in a for loop, with a sleep between each branch. On high-latency networks (me!), the sleep might need to be a few seconds long.Tor: 0.4.2.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/29762Update the README for new features2020-06-13T13:30:50ZteorUpdate the README for new featuresWe've added a few new features to chutney recently, so we should update the README. (And keep it up to date when we make future changes.)We've added a few new features to chutney recently, so we should update the README. (And keep it up to date when we make future changes.)teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29760Stop repeating chutney's defaults in comments2020-06-13T13:30:49ZteorStop repeating chutney's defaults in commentsWhen we repeat the defaults in comments and code, the comments get out of date,
Example:
```
# chutney starts verifying after START seconds, keeps on trying for BOOTSTRAP seconds,
# and then stops after STOP seconds (see the defaults be...When we repeat the defaults in comments and code, the comments get out of date,
Example:
```
# chutney starts verifying after START seconds, keeps on trying for BOOTSTRAP seconds,
# and then stops after STOP seconds (see the defaults below)
```
https://github.com/teor2345/chutney/pull/2/files#r264898496teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29690Add a comment to chutney's test-network.sh, reminding us to copy changes to t...2020-06-13T13:30:45ZteorAdd a comment to chutney's test-network.sh, reminding us to copy changes to tor's test-network.shSee #29689 for details.See #29689 for details.https://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/29631protover: Rust missing Padding value in translate_to_rust()2020-06-13T15:53:39ZDavid Gouletdgoulet@torproject.orgprotover: Rust missing Padding value in translate_to_rust()Noticed that when I was adding the protover support in #26288.Noticed that when I was adding the protover support in #26288.Tor: 0.4.1.x-finalhttps://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 Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29612Update the documentation for ExitRelay2020-06-13T15:38:45ZteorUpdate the documentation for ExitRelayIn #21530 in 0.3.5, we changed the default of ExitRelay: relays used to be exits by default, but now they are not.
But we forgot to update the documentation.In #21530 in 0.3.5, we changed the default of ExitRelay: relays used to be exits by default, but now they are not.
But we forgot to update the documentation.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29578The bandwidth file is not a fallback list2020-06-13T15:38:33ZteorThe bandwidth file is not a fallback listTor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29530Some address/get_if_addrs* tests fail when the network is unreachable2020-06-13T15:38:19ZteorSome address/get_if_addrs* tests fail when the network is unreachableI see these failures when my network connection is off:
```
address/get_if_addrs_list_internal: Feb 19 21:28:39.823 [err] connect() failed:
Network is unreachable
[get_if_addrs_list_internal FAILED]
address/get_if_addrs_list_no_inter...I see these failures when my network connection is off:
```
address/get_if_addrs_list_internal: Feb 19 21:28:39.823 [err] connect() failed:
Network is unreachable
[get_if_addrs_list_internal FAILED]
address/get_if_addrs_list_no_internal: Feb 19 21:28:39.825 [err] connect() failed: Network is unreachable
[get_if_addrs_list_no_internal FAILED]
address/get_if_addrs6_list_internal: OK
address/get_if_addrs6_list_no_internal: [forking] OK
address/get_if_addrs_internal_fail: OK
address/get_if_addrs_no_internal_fail: OK
address/get_if_addrs: Feb 19 21:28:39.881 [err] connect() failed: Network is unreachable
[get_if_addrs FAILED]
```
The quick fix is to downgrade them to warnings.Tor: 0.3.5.x-finalNick MathewsonNick Mathewson