The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-06-23T17:24:14Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31375hs: Crash in token_bucket_ctr_refill() of the INTRO2 DoS defense2021-06-23T17:24:14ZDavid Gouletdgoulet@torproject.orghs: Crash in token_bucket_ctr_refill() of the INTRO2 DoS defenseRan my relay for some minutes with master (merged legacy/trac#15516) and the HS DoS defenses enabled. Relay died with this:
```
Tor 0.4.2.0-alpha-dev (git-0acfd7dcee2a4473) died: Caught signal 8
/home/tor/git/tor/src/app/tor(+0x20d359)[...Ran my relay for some minutes with master (merged legacy/trac#15516) and the HS DoS defenses enabled. Relay died with this:
```
Tor 0.4.2.0-alpha-dev (git-0acfd7dcee2a4473) died: Caught signal 8
/home/tor/git/tor/src/app/tor(+0x20d359)[0x5594030b1359]
/home/tor/git/tor/src/app/tor(token_bucket_ctr_refill+0x3b)[0x55940304c33b]
/home/tor/git/tor/src/app/tor(token_bucket_ctr_refill+0x3b)[0x55940304c33b]
/home/tor/git/tor/src/app/tor(hs_dos_can_send_intro2+0x45)[0x559402fb6ba5]
/home/tor/git/tor/src/app/tor(rend_mid_introduce_legacy+0x136)[0x559402ff7096]
/home/tor/git/tor/src/app/tor(hs_intro_received_introduce1+0x2ce)[0x5594030457ee]
/home/tor/git/tor/src/app/tor(rend_process_relay_cell+0x1bf)[0x559402ff643f]
/home/tor/git/tor/src/app/tor(+0xb9105)[0x559402f5d105]
/home/tor/git/tor/src/app/tor(+0xb9b60)[0x559402f5db60]
/home/tor/git/tor/src/app/tor(circuit_receive_relay_cell+0x490)[0x559402f5f590]
/home/tor/git/tor/src/app/tor(command_process_cell+0x3f8)[0x559402f40ed8]
/home/tor/git/tor/src/app/tor(channel_tls_handle_cell+0x39b)[0x559402f2078b]
/home/tor/git/tor/src/app/tor(+0xa5a9c)[0x559402f49a9c]
/home/tor/git/tor/src/app/tor(connection_handle_read+0xa0d)[0x559402f0dd0d]
/home/tor/git/tor/src/app/tor(+0x6ef1e)[0x559402f12f1e]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x1e8f8)[0x7f15b29208f8]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x53f)[0x7f15b292133f]
/home/tor/git/tor/src/app/tor(do_main_loop+0xd9)[0x559402f14209]
/home/tor/git/tor/src/app/tor(tor_run_main+0x128d)[0x559402f01d9d]
/home/tor/git/tor/src/app/tor(tor_main+0x3a)[0x559402eff1da]
/home/tor/git/tor/src/app/tor(main+0x19)[0x559402efed69]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f15b1bbbb97]
```Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31374Appveyor: cast between incompatible function types in compat_time2020-06-27T13:49:40ZteorAppveyor: cast between incompatible function types in compat_timeThe latest Appveyor compiler complains:
{{{
../src/lib/time/compat_time.c:522:25: error: cast between incompatible function types from 'FARPROC' to 'ULONGLONG (__attribute__((stdcall)) *)(void)' [-Werror=cast-function-type]
522 | ...The latest Appveyor compiler complains:
{{{
../src/lib/time/compat_time.c:522:25: error: cast between incompatible function types from 'FARPROC' to 'ULONGLONG (__attribute__((stdcall)) *)(void)' [-Werror=cast-function-type]
522 | GetTickCount64_fn = (GetTickCount64_fn_t)
| ^
}}}
This issue is like legacy/trac#27465:
GetProcAddress() returns FARPROC, which is (long long int(*)()) on
64-bit Windows:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx
But GetTickCount64() is (long long unsigned int(*)()), on both 32-bit
and 64-bit Windows:
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount64
So gcc 8 issues a spurious "incompatible function pointer" warning
about the cast to GetTickCount64_fn_t.
Silence this warning by casting to a void function pointer, before
the cast to GetTickCount64_fn_t.
Fixes bug NNNNN; bugfix on 0.2.9.1-alpha.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31373Print summary of features at end of configure2020-06-27T13:49:40ZDavid Gouletdgoulet@torproject.orgPrint summary of features at end of configureI came across this summary with colors in another open source project. I borrowed their m4 pretty print macro that is GPLv2.
I took 15 minutes to make this and it is actually very useful to have such a summary at the end of configure ti...I came across this summary with colors in another open source project. I borrowed their m4 pretty print macro that is GPLv2.
I took 15 minutes to make this and it is actually very useful to have such a summary at the end of configure time instead of looking at config.log all the time to make sure what you have enabled.
See attachment for the end result.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31372Appveyor and Travis should use "make -k"2020-06-27T13:49:41ZNick MathewsonAppveyor and Travis should use "make -k"Right now our .appveyor.yml and .travis.yml are not using the "-k" make flag. That means that once it encounters an error, it stops building. In general, we would prefer our CI to keep trying to build for a long as it can, so that we c...Right now our .appveyor.yml and .travis.yml are not using the "-k" make flag. That means that once it encounters an error, it stops building. In general, we would prefer our CI to keep trying to build for a long as it can, so that we can see all of the warnings and errors that are produced. This will help us save round trips between the developer and the CI process.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31371hs: Add DoS defense counter to DoS heartbeat message2021-06-23T17:24:14ZDavid Gouletdgoulet@torproject.orghs: Add DoS defense counter to DoS heartbeat messageNow that legacy/trac#15516 is merged, we'll soon enable those defenses and it would be nice to have the counter of how many introduction were rejected due to DoS defenses.Now that legacy/trac#15516 is merged, we'll soon enable those defenses and it would be nice to have the counter of how many introduction were rejected due to DoS defenses.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31366Move the connection_edge_process_relay_cell() assignment out of the if statem...2021-09-16T14:23:38ZNeel Chauhanneel@neelc.orgMove the connection_edge_process_relay_cell() assignment out of the if statement in circuit_receive_relay_cell()As mentioned in legacy/trac#31207 by nickm:
>This is fine. I'd also take a patch to extract the assignment entirely, since using assignment in this way is error-prone.As mentioned in legacy/trac#31207 by nickm:
>This is fine. I'd also take a patch to extract the assignment entirely, since using assignment in this way is error-prone.Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31364tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:494: warn_if_nu...2023-07-16T12:12:44ZTractor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:494: warn_if_nul_found: Non-fatal assertion !(nul_found) failed. (on Tor 0.4.0.5) [also on 0.4.5.8]
```
Aug 07 11:00:15.000 [notice] Tor 0.4.0.5 opening log file.
Aug 07 11:00:15.393 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 101000af: ...
```
Aug 07 11:00:15.000 [notice] Tor 0.4.0.5 opening log file.
Aug 07 11:00:15.393 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 101000af: OpenSSL 1.1.0j 20 Nov 2018; running with 101000bf: OpenSSL 1.1.0k 28 May 2019).
Aug 07 11:00:15.395 [notice] Can't get entropy from getrandom(). You are running a version of Tor built to support getrandom(), but the kernel doesn't implement this function--probably because it is too old? Trying fallback method instead.
Aug 07 11:00:15.398 [notice] Tor 0.4.0.5 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0k, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Aug 07 11:00:15.398 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download
Aug 07 11:00:15.398 [warn] Tor was compiled with zstd 1.1.2, but is running with zstd 1.3.8. For safety, we'll avoid using advanced zstd functionality.
Aug 07 11:00:15.399 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Aug 07 11:00:15.399 [notice] Read configuration file "/etc/tor/torrc".
Aug 07 11:00:15.407 [notice] Based on detected system memory, MaxMemInQueues is set to 384 MB. You can override this by setting MaxMemInQueues by hand.
Aug 07 11:00:15.410 [notice] I think we have 40 CPUS, but only 1 of them are available. Telling Tor to only use 1. You can override this with the NumCPUs option
Aug 07 11:00:15.411 [notice] Opening OR listener on 0.0.0.0:443
Aug 07 11:00:15.411 [notice] Opened OR listener on 0.0.0.0:443
Aug 07 11:00:15.411 [notice] Opening OR listener on [***]:443
Aug 07 11:00:15.412 [notice] Opened OR listener on [***]:443
Aug 07 11:00:15.412 [notice] Opening Directory listener on 0.0.0.0:9030
Aug 07 11:00:15.412 [notice] Opened Directory listener on 0.0.0.0:9030
Aug 07 11:00:15.000 [notice] Not disabling debugger attaching for unprivileged users.
Aug 07 11:00:15.000 [warn] Found empty file "1037" in consensus cache; removing it.
Aug 07 11:00:15.000 [warn] Unable to map file (null) from consensus cache: No such file or directory
Aug 07 11:00:16.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Aug 07 11:00:17.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Aug 07 11:00:17.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Aug 07 11:00:17.000 [notice] Your Tor server's identity key fingerprint is '***'
Aug 07 11:00:17.000 [notice] Bootstrapped 0% (starting): Starting
Aug 07 11:00:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:494: warn_if_nul_found: Non-fatal assertion !(nul_found) failed. (on Tor 0.4.0.5)
Aug 07 11:00:17.000 [warn] Bug: Non-fatal assertion !(nul_found) failed in warn_if_nul_found at ../src/feature/nodelist/microdesc.c:494. Stack trace: (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x47) [0x55e3b15b98e7] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x55e3b15b4db0] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(+0x11e43f) [0x55e3b14d643f] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(microdesc_cache_reload+0xce) [0x55e3b14d89ee] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(get_microdesc_cache+0x48) [0x55e3b14d8ad8] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(nodelist_set_consensus+0x3fd) [0x55e3b14e4e3d] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(networkstatus_set_current_consensus+0x927) [0x55e3b14dd9d7] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(+0x125dfe) [0x55e3b14dddfe] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(router_reload_consensus_networkstatus+0x45) [0x55e3b14ddeb5] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(run_tor_main_loop+0xec) [0x55e3b141564c] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x11e5) [0x55e3b1416b05] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x55e3b1413c8a] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x55e3b1413809] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f10090512e1] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x55e3b141385a] (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] warn_if_nul_found(): Bug: Found unexpected NUL while reading microdesc journal, offset 0at position 295945/331210. (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] warn_if_nul_found(): Bug: surrounding string: 595630544A522B5159546D49496A300A00000000000000000000000000000000 (on Tor 0.4.0.5 )
Aug 07 11:00:17.000 [warn] parse error: internal NUL character.
Aug 07 11:00:17.000 [warn] Unparseable microdescriptor found in journal
Aug 07 11:00:27.000 [notice] Starting with guard context "default"
Aug 07 11:00:27.000 [notice] Signaled readiness to systemd
Aug 07 11:00:27.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
```
Apart from that error message Tor seems to work fine.
The relay was running on a VM and when i saw that error the whole VM behaved strange. I think the ISP corrupted something so maybe that error isnt Tor's fault.
**Trac**:
**Username**: computer_freakTor: 0.4.7.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/31359Split a control_event module out of control, and make it use control safe log...2020-06-27T13:49:41ZteorSplit a control_event module out of control, and make it use control safe loggingCurrently, control events can log messages through the standard logging module, which can send those logs as control events. This means that some configurations, future code, or errors might cause an infinite loop.
We should split off ...Currently, control events can log messages through the standard logging module, which can send those logs as control events. This means that some configurations, future code, or errors might cause an infinite loop.
We should split off a control_event or control_log_event module, and make it use control safe logging. All it's dependencies should also use control safe or signal safe logging.
I think we need to make this change after catalyst's control refactor, to avoid merge conflicts.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/313560.4.1 relays should list Padding=22020-06-27T13:49:41ZMike Perry0.4.1 relays should list Padding=2Somehow we accidentally merged the protover for padding support while doing the incremental merge thing, and 0.4.0 relays are advertising padding that they don't support. This is mostly harmless, because the negotiation will not succeed ...Somehow we accidentally merged the protover for padding support while doing the incremental merge thing, and 0.4.0 relays are advertising padding that they don't support. This is mostly harmless, because the negotiation will not succeed and then clients will stop, but it will result in those clients emitting a "Middle node did not accept our padding request" protocol warn/info message.
~~We should just remove this protover field from 0.4.0.x.~~
At the weekly meeting last week, we decided that we can't remove a protover once it's been released.
Instead, we will:
* make 0.4.1 and later relays declare Padding=2 (pre-0.4.1 stable)
* make 0.4.1 and later clients require Padding=2 (padding is not on by default, so we can do this at any time)
Edited to simplify: we don't need to preserve compatibility with alphas.Tor: 0.4.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31354Compiler "note" in test_addr.c: variable tracking size limit exceeded with ‘-...2020-06-27T13:49:41ZNick MathewsonCompiler "note" in test_addr.c: variable tracking size limit exceeded with ‘-fvar-tracking-assignments’Building with GCC 9.1.1, I see these:
```
src/test/test_addr.c: In function ‘test_addr_parse’:
src/test/test_addr.c:1167:1: note: variable tracking size limit exceeded with ‘-fvar-tracking-assignments’, retrying without
1167 | test_add...Building with GCC 9.1.1, I see these:
```
src/test/test_addr.c: In function ‘test_addr_parse’:
src/test/test_addr.c:1167:1: note: variable tracking size limit exceeded with ‘-fvar-tracking-assignments’, retrying without
1167 | test_addr_parse(void *arg)
| ^~~~~~~~~~~~~~~
```
This seems to be new in 0.4.2.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31353Jenkins failure on windows: Overflow in implicit constant conversion2020-06-27T13:49:41ZNick MathewsonJenkins failure on windows: Overflow in implicit constant conversion```
08:59:20 ../tor/src/test/test_token_bucket.c: In function 'test_token_bucket_ctr_dec':
08:59:20 ../tor/src/test/test_token_bucket.c:96:3: error: overflow in implicit constant conversion [-Werror=overflow]
```
This appears to be new ...```
08:59:20 ../tor/src/test/test_token_bucket.c: In function 'test_token_bucket_ctr_dec':
08:59:20 ../tor/src/test/test_token_bucket.c:96:3: error: overflow in implicit constant conversion [-Werror=overflow]
```
This appears to be new in 7cf9d54e6d7a08f169a27f7d76731e61ebe63fb0, which is not in anything before 0.4.2.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31352Jenkins failure on windows: ENETUNREACH undeclared.2020-06-27T13:49:42ZNick MathewsonJenkins failure on windows: ENETUNREACH undeclared.On https://jenkins.torproject.org/job/tor-ci-windows-master/22/consoleFull I see:
```
08:59:23 ../tor/src/test/test_util.c:5402:39: error: 'ENETUNREACH' undeclared (first use in this function)
```
This appears to be new in c46e99c43c4e...On https://jenkins.torproject.org/job/tor-ci-windows-master/22/consoleFull I see:
```
08:59:23 ../tor/src/test/test_util.c:5402:39: error: 'ENETUNREACH' undeclared (first use in this function)
```
This appears to be new in c46e99c43c4ee03, which is not in anything before 0.4.2.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31343appveyor: labs(time_t) is not allowed2020-06-27T13:49:42ZNick Mathewsonappveyor: labs(time_t) is not allowedMike points out that appveyor is failing with
```
../src/core/or/channeltls.c:1768:7: error: absolute value function 'labs' given an argument of type 'time_t' {aka 'long long int'} but has parameter of type 'long int' which may cause tr...Mike points out that appveyor is failing with
```
../src/core/or/channeltls.c:1768:7: error: absolute value function 'labs' given an argument of type 'time_t' {aka 'long long int'} but has parameter of type 'long int' which may cause truncation of value [-Werror=absolute-value]
1768 | if (labs(now - chan->conn->handshake_state->sent_versions_at) < 180) {
| ^~~~
```
That code has been there for ages, though. Looks like this is a new compiler warning rather than a new bug. It is a c issue, though, anywhere that time_t is bigger than long.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31340Tor sometimes stalls traffic at 2s intervals (6s most common)2022-06-24T16:03:24ZMike PerryTor sometimes stalls traffic at 2s intervals (6s most common)Dennis Jackson found some very suspicious performance issues while scanning the Tor network:
https://lists.torproject.org/pipermail/tor-scaling/2019-July/000063.html
The "6s delay" mystery there looks like some kind of relay bug. There ...Dennis Jackson found some very suspicious performance issues while scanning the Tor network:
https://lists.torproject.org/pipermail/tor-scaling/2019-July/000063.html
The "6s delay" mystery there looks like some kind of relay bug. There are smaller bumps for delays at 2s multiples.. Cause is still unknown. We should track this one down and fix it.https://gitlab.torproject.org/tpo/core/tor/-/issues/31338Practracker --list-overbroad produces confusing output when there is an excep...2020-06-27T13:49:42ZteorPractracker --list-overbroad produces confusing output when there is an exceptionconnection_control_process_inbuf() is 115 lines long, but the exceptions file says it should be 113.
This line is spurious and should not appear in the output:
```
problem function-size /src/feature/control/control.c:connection_control_...connection_control_process_inbuf() is 115 lines long, but the exceptions file says it should be 113.
This line is spurious and should not appear in the output:
```
problem function-size /src/feature/control/control.c:connection_control_process_inbuf() 113 -> 0
```
Ideally, practracker should log a message that there are no over-broad exceptions, but there are violations.
Here is the full output:
```
$ scripts/maint/practracker/practracker.py --list-overbroad
problem function-size /src/feature/control/control.c:connection_control_process_inbuf() 115
FAILURE: practracker found 1 new problem(s) in the code: see warnings above.
Please fix the problems if you can, and update the exceptions file
(./scripts/maint/practracker/./exceptions.txt) if you can't.
See doc/HACKING/HelpfulTools.md for more information on using practracker.
You can disable this message by setting the TOR_DISABLE_PRACTRACKER environment
variable.
problem function-size /src/feature/control/control.c:connection_control_process_inbuf() 113 -> 0
Exit 1
```Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31336Fix usage for add_c_file.py2020-06-27T13:49:42ZteorFix usage for add_c_file.pyadd_c_file.py was added in commit 2f31c8146f in 0.4.1.2-alpha.
But it has a bug: the suggested usage fails with:
```
$ scripts/maint/add_c_file.py ./src/feature/dirauth/ocelot.c
Made files successfully but couldn't identify include.am f...add_c_file.py was added in commit 2f31c8146f in 0.4.1.2-alpha.
But it has a bug: the suggested usage fails with:
```
$ scripts/maint/add_c_file.py ./src/feature/dirauth/ocelot.c
Made files successfully but couldn't identify include.am for ./src/feature/dirauth/ocelot.c
Exit 1
```
The correct usage has no "./":
```
$ scripts/maint/add_c_file.py src/feature/dirauth/ocelot.c
```
We should fix the usage, or make topdir_file() use python's canonical path functions.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31335make check-includes does not check out of tree builds correctly2020-06-27T13:49:42Zteormake check-includes does not check out of tree builds correctlyI configure tor to build with an out-of-tree build in tor/build-c.
When I run "make check-includes", it checks tor/build-c/src. But it should check tor/src.
I'm marking this as a sponsor 31 roadmap item, because we need to get this che...I configure tor to build with an out-of-tree build in tor/build-c.
When I run "make check-includes", it checks tor/build-c/src. But it should check tor/src.
I'm marking this as a sponsor 31 roadmap item, because we need to get this check working, so we know that legacy/trac#29217 creates new modules correctly.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31334Use SEVERITY_MASK_IDX() to find the LOG_ERR index in the unit tests2020-06-27T13:49:43ZteorUse SEVERITY_MASK_IDX() to find the LOG_ERR index in the unit testsPart of legacy/trac#30901, just needed a bug number.Part of legacy/trac#30901, just needed a bug number.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31333reduce fingerprints len by 32.5% to reduce descriptors size2020-06-27T13:49:43Zcypherpunksreduce fingerprints len by 32.5% to reduce descriptors sizeI have read proposals to reduce descriptor size and found fingerprints use SHA1, why not use base64 for them to change for example:
moria relay:
SHA1:
```
string(40) "9695DFC35FFEB861329B9F1AB04C46397020CE31"
```
base64 without trailing...I have read proposals to reduce descriptor size and found fingerprints use SHA1, why not use base64 for them to change for example:
moria relay:
SHA1:
```
string(40) "9695DFC35FFEB861329B9F1AB04C46397020CE31"
```
base64 without trailing padding:
```
string(27) "lpXfw1/+uGEym58asExGOXAgzjE"
```
pseudocode for example:
```
substr(base64_encode(hex2bin('9695DFC35FFEB861329B9F1AB04C46397020CE31')),0,27)
```
results into 32.5% less fingerprints stringlen.https://gitlab.torproject.org/tpo/core/tor/-/issues/31320Add an IPv6 ORPort example to the torrc.minimal.in-staging and torrc.sample.i...2021-07-22T16:19:44ZteorAdd an IPv6 ORPort example to the torrc.minimal.in-staging and torrc.sample.in filesWe don't currently have any IPv6 ORPorts in the example torrc files, but we should.We don't currently have any IPv6 ORPorts in the example torrc files, but we should.Tor: unspecified