The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:49:30Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31611Work out why chutney didn't fail due to #31495 cannot configure bridges2020-06-27T13:49:30ZteorWork out why chutney didn't fail due to #31495 cannot configure bridgesIn legacy/trac#31495, Tor Browser failed, but our chutney CI job did not fail. Let's work out why that happened.In legacy/trac#31495, Tor Browser failed, but our chutney CI job did not fail. Let's work out why that happened.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31608circuit_state_publish() never triggers when a new origin circuit is created2022-06-17T13:10:18ZDavid Gouletdgoulet@torproject.orgcircuit_state_publish() never triggers when a new origin circuit is createdIn `origin_circuit_init()`, we change the circuit state before allocating the `build_state` but also before a purpose is set.
This means that `circuit_state_publish()` located in `circuit_set_state()` is never called for a new circuit b...In `origin_circuit_init()`, we change the circuit state before allocating the `build_state` but also before a purpose is set.
This means that `circuit_state_publish()` located in `circuit_set_state()` is never called for a new circuit because `CIRCUIT_IS_ORIGIN()` doesn't return true.
Which in turn, by chance I believe, made this NULL deref on `build_state` to never happen.
This should be fixed regardless.https://gitlab.torproject.org/tpo/core/tor/-/issues/31594Close all the log fds before aborting2020-07-14T22:24:28ZteorClose all the log fds before abortingWe should close the sigsafe_log_fds before abort(), so that we are less likely to lose log lines in the fd buffers.
Here are the abort() users:
* tor_abort_()
* crash_handler()
* format_number_sigsafe()
* raw_assert()
* raw_assert_unrea...We should close the sigsafe_log_fds before abort(), so that we are less likely to lose log lines in the fd buffers.
Here are the abort() users:
* tor_abort_()
* crash_handler()
* format_number_sigsafe()
* raw_assert()
* raw_assert_unreached_msg()
* trunnel_abort()
We could:
* define a raw_abort() function that closes the fds
* use it instead of abort()
* #define trunnel_abort() as raw_abort()
* update our C linter to require raw_abort() instead of abort()Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31589hs-v3: Simplify decrypt_desc_layer interface2021-09-16T14:22:37ZGeorge Kadianakishs-v3: Simplify decrypt_desc_layer interfaceHere is how `decrypt_desc_layer` is called:
```
superencrypted_len = decrypt_desc_layer(desc,
desc->plaintext_data.superencrypted_blob,
desc->plaintext_data.superencrypt...Here is how `decrypt_desc_layer` is called:
```
superencrypted_len = decrypt_desc_layer(desc,
desc->plaintext_data.superencrypted_blob,
desc->plaintext_data.superencrypted_blob_size,
NULL, 1, &superencrypted_plaintext);
```
```
encrypted_len = decrypt_desc_layer(desc,
desc->superencrypted_data.encrypted_blob,
desc->superencrypted_data.encrypted_blob_size,
descriptor_cookie, 0, &encrypted_plaintext);
```
There is no point in passing `desc->superencrypted_data.encrypted_blob` and `desc->superencrypted_data.encrypted_blob_size` since we are already passing the whole `desc` and `is_superencrypted_layer` which should be enough to figure out which fields to use.
We could either of the following two things:
- Ditch `desc` as an argument and pass `desc->plaintext_data.blinded_pubkey` explicitly.
- Ditch `encrypted_blob` and `encrypted_blob_size` as arguments and get them off desc.
I prefer the first, but I'm fine with either, since it will make the interface cleaner.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31579Space out the arguments to the cell functions in rend_process_relay_cell()2020-06-27T13:49:31ZNeel Chauhanneel@neelc.orgSpace out the arguments to the cell functions in rend_process_relay_cell()In the `switch (command) {` statement in `rend_process_relay_cell()`, arguments to the functions corresponding to cells aren't spaced, like:
```
r = hs_intro_received_establish_intro(or_circ,payload,length);
```In the `switch (command) {` statement in `rend_process_relay_cell()`, arguments to the functions corresponding to cells aren't spaced, like:
```
r = hs_intro_received_establish_intro(or_circ,payload,length);
```Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31578practracker scans build directories inside the tor/ directory2020-06-27T13:49:31Zteorpractracker scans build directories inside the tor/ directoryWhen I run practracker after the failed "make distcheck" in legacy/trac#31577, I get these errors:
```
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.c:socks4_client_request_encode() 352
problem function-size /b...When I run practracker after the failed "make distcheck" in legacy/trac#31577, I get these errors:
```
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.c:socks4_client_request_encode() 352
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.c:socks4_client_request_parse_into() 332
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.c:socks5_client_request_encode() 113
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.c:socks5_server_reply_encode() 113
problem file-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/socks5.h 995
problem function-size /build-c/tor-0.4.2.0-alpha-dev/src/trunnel/hs/cell_introduce1.c:trn_cell_introduce_encrypted_encode() 110
(warning) problem file-size /src/core/or/circuitpadding.c 3096
(warning) problem function-size /src/core/or/circuitpadding.c:circpad_machine_schedule_padding() 113
(warning) problem file-size /src/core/or/circuitpadding.h 813
(warning) problem file-size /src/core/or/relay.c 3264
(warning) problem file-size /src/feature/hs/hs_service.c 4125
(warning) problem file-size /src/feature/nodelist/routerlist.c 3241
(warning) problem function-size /src/feature/rend/rendmid.c:rend_mid_establish_intro_legacy() 105
(warning) problem file-size /src/feature/rend/rendservice.c 4522
(warning) problem function-size /src/feature/rend/rendservice.c:rend_service_receive_introduction() 334
FAILURE: practracker found 482 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.
make[1]: *** [check-best-practices] Error 226
make[1]: *** Waiting for unfinished jobs....
```Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31577make distcheck on macOS ignores --disable-asciidoc in its second configure in...2020-06-27T13:49:31Zteormake distcheck on macOS ignores --disable-asciidoc in its second configure invocationI build tor on macos using:
```
git clone https://git.torproject.org/tor.git
cd tor
mkdir build-c
../configure --disable-asciidoc --with-libevent-dir=/usr/local --with-openssl-dir=/usr/local/opt/openssl --enable-lzma --enable-zstd --enab...I build tor on macos using:
```
git clone https://git.torproject.org/tor.git
cd tor
mkdir build-c
../configure --disable-asciidoc --with-libevent-dir=/usr/local --with-openssl-dir=/usr/local/opt/openssl --enable-lzma --enable-zstd --enable-libscrypt CC=clang --enable-gcc-warnings --enable-expensive-hardening
make distcheck
```
Which fails with:
```
checking whether the compiler accepts @warning_flags... yes
==================================
Building Tor has failed since manpages cannot be built.
You need asciidoc installed to be able to build the manpages.
To build without manpages, use the --disable-asciidoc argument
when calling configure.
==================================
make: *** [distcheck] Error 1
Exit 2
```
What am I doing wrong?
Does "make distcheck" support a build directory inside tor/ ?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31576Remove/stop shipping contrib/dist/rc.subr2020-06-27T13:49:31ZteorRemove/stop shipping contrib/dist/rc.subrIt appears FreeBSD no longer needs it.It appears FreeBSD no longer needs it.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31571Add the tor version and a newline to raw_assert()2020-07-14T22:24:18ZteorAdd the tor version and a newline to raw_assert()We're missing a newline and the tor version in the logs for legacy/trac#31570.We're missing a newline and the tor version in the logs for legacy/trac#31570.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31570INTERNAL ERROR: raw assertion failed (core dump) in termux2020-07-14T22:24:17ZTracINTERNAL ERROR: raw assertion failed (core dump) in termuxSo, I have fresh install of termux in my phone no matter if i reinstall the termux tor will crash in start does anybudy can track it down ?
```
==============================================================T= 1567005970
INTERNAL ERROR:...So, I have fresh install of termux in my phone no matter if i reinstall the termux tor will crash in start does anybudy can track it down ?
```
==============================================================T= 1567005970
INTERNAL ERROR: Raw assertion failed at /home/builder/.termux-build/tor/src/src/lib/malloc/map_anon.c:213: nodump_result == 0Aborted (core dumped)
```
Additional information:
https://github.com/termux/termux-packages/issues/4235
https://tor.stackexchange.com/questions/20222/internal-error-raw-assertion
**Trac**:
**Username**: foremtehanTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31565static Tor building against openssl-1.1.1 fails: configure unable to find lin...2020-07-29T13:10:29ZTracstatic Tor building against openssl-1.1.1 fails: configure unable to find linkable OpenSSLTrying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4...Trying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4.0.5 and 0.4.1.5. Building against openssl-1.0.2 works.
**Trac**:
**Username**: shredderTor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/31561hs-v3: Service can keep unused intro points in its list2021-06-23T17:24:15ZDavid Gouletdgoulet@torproject.orghs-v3: Service can keep unused intro points in its listTor always selects an extra number of intro points in addition to the configured `HiddenServiceNumIntroductionPoints`.
It launches all of them and the first `NumIntro...` to finish are used (considering legacy/trac#31548 is resolved).
...Tor always selects an extra number of intro points in addition to the configured `HiddenServiceNumIntroductionPoints`.
It launches all of them and the first `NumIntro...` to finish are used (considering legacy/trac#31548 is resolved).
Once the circuit of the remaining intro opens, we notice that we have too many and then re-purpose the extra ones.
However, I've noticed that sometimes establishing an intro circuit timeouts during build, basically expiring due to our CBT policy. In that case, the circuit is simply close but the intro point remains in the service descriptor list.
This is bad because of legacy/trac#31548, this means an intro point can end up in the descriptor even though the service never established any circuits to it...
We simply need to callback into the HS subsystem when we are expiring an HS circuit so appropriate actions can be taken such as in this case, removing the IP from the list.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31560Should we CI-build with --disable-module-dirauth and -O0?2021-02-05T21:03:36ZNick MathewsonShould we CI-build with --disable-module-dirauth and -O0?In legacy/trac#31552, I diagnosed a bug that only appears in two circumstances:
* on Android with LTO and --disable-module-dirauth
* elsewhere with -O0 and --disable-module-dirauth
Is it worthwhile adding a CI case for this, perha...In legacy/trac#31552, I diagnosed a bug that only appears in two circumstances:
* on Android with LTO and --disable-module-dirauth
* elsewhere with -O0 and --disable-module-dirauth
Is it worthwhile adding a CI case for this, perhaps on a cron job?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31559test-timers fail on maint-0.2.92020-06-27T13:49:32Zteortest-timers fail on maint-0.2.9```
FAIL: src/test/test-timers
==========================
mean difference: 183123 usec
standard deviation: 524773.950303 usec
Either your system is under ridiculous load, or the timer backend is broken.
FAIL src/test/test-timers (ex...```
FAIL: src/test/test-timers
==========================
mean difference: 183123 usec
standard deviation: 524773.950303 usec
Either your system is under ridiculous load, or the timer backend is broken.
FAIL src/test/test-timers (exit status: 1)
```
https://travis-ci.org/torproject/tor/jobs/575709059#L2759
I wonder if this is a once-off, or if we haven't backported enough timer patches to 0.2.9.
I'll re-run the job, and see what happens.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31554Restrict "make test-stem" to tests that actually use tor2020-06-27T13:49:32ZteorRestrict "make test-stem" to tests that actually use torIn legacy/trac#30694, we restricted the travis stem job to tests that actually use tor.
But we should lower that change to "make test-stem".
Gaba, this is sponsor 27 can, because it makes refactoring easier to test.In legacy/trac#30694, we restricted the travis stem job to tests that actually use tor.
But we should lower that change to "make test-stem".
Gaba, this is sponsor 27 can, because it makes refactoring easier to test.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31552--disable-module-dirauth broken (missing symbols)2020-06-27T13:49:32ZTrac--disable-module-dirauth broken (missing symbols)build with ./configure --disable-module-dirauth
this will fail at linking time because of missing symbols.
It used to work in 0.4.0.5 and is broken in 0.4.1.5
for example
```
make: *** [Makefile:9672: src/app/tor] Error 1
ld.lld: er...build with ./configure --disable-module-dirauth
this will fail at linking time because of missing symbols.
It used to work in 0.4.0.5 and is broken in 0.4.1.5
for example
```
make: *** [Makefile:9672: src/app/tor] Error 1
ld.lld: error: undefined symbol: dirserv_should_launch_reachability_test
>>> referenced by ld-temp.o
>>> lto.tmp:(routers_update_status_from_consensus_networkstatus)
ld.lld: error: undefined symbol: authdir_wants_to_reject_router
>>> referenced by ld-temp.o
>>> lto.tmp:(router_add_to_routerlist)
ld.lld: error: undefined symbol: dirserv_would_reject_router
>>> referenced by ld-temp.o
>>> lto.tmp:(update_consensus_router_descriptor_downloads)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
**Trac**:
**Username**: LarryBitcoinTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31549Authorities should stop listing relays running pre-0.2.9, or running 0.3.0 th...2022-02-03T16:25:08ZNick MathewsonAuthorities should stop listing relays running pre-0.2.9, or running 0.3.0 through 0.3.4The release series 0.3.0 through 0.3.4 are no longer supported, and we have encountered at least one bug (legacy/trac#27841) caused by them lingering on the network.
We should have the authorities stop listing them in their votes. The...The release series 0.3.0 through 0.3.4 are no longer supported, and we have encountered at least one bug (legacy/trac#27841) caused by them lingering on the network.
We should have the authorities stop listing them in their votes. The patch here is simple enough -- we just edit dirserv_get_status_impl to reject everything newer than "0.3.0.0" and less new than "0.3.5.x" (for some well chosen "x").
But before we do this, we should take necessary steps to contact operators and let them know that they really really need to upgrade.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31548hs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro po...2021-06-23T17:24:15ZDavid Gouletdgoulet@torproject.orghs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro pointsDuring my testing of legacy/trac#30200, I ended up with service descriptor with 4 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3 (default).
Further investigation confirmed this by adding a log in the `decode_i...During my testing of legacy/trac#30200, I ended up with service descriptor with 4 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3 (default).
Further investigation confirmed this by adding a log in the `decode_intro_points()` function which showed me 4 intro points.
I haven't found out why but one feature of HS is that we launch `HiddenServiceNumIntroductionPoints` + 2 intro circuits in parallel and the first one to finish are picked.
It appears that more than the defined value can finish at the same time and will be picked.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31545CID 1452819: nul-terminated string handling, possibly spurious2020-06-27T13:49:33ZteorCID 1452819: nul-terminated string handling, possibly spuriousBug introduced by legacy/trac#21003, copying sponsors and tags.
```
/src/feature/nodelist/describe.c: 77 in format_node_description()
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
...Bug introduced by legacy/trac#21003, copying sponsors and tags.
```
/src/feature/nodelist/describe.c: 77 in format_node_description()
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
76 if (has_addr) {
CID 1452819: (STRING_NULL)
Passing unterminated string "cp" to "tor_addr_to_str", which expects a null-terminated string.
77 tor_addr_to_str(cp, addr, TOR_ADDR_BUF_LEN, 1);
78 }
79
80 return buf;
81 }
82
/src/feature/nodelist/describe.c: 70 in format_node_description()
64 cp += 4;
65 }
66 if (addr32h) {
67 struct in_addr in;
68 in.s_addr = htonl(addr32h);
69 tor_inet_ntoa(&in, cp, INET_NTOA_BUF_LEN);
CID 1452819: (STRING_NULL)
Passing unterminated string "cp" to "strlen", which expects a null-terminated string.
70 cp += strlen(cp);
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
```
I think the best fix for this issue is using strncpy() rather than memcpy().Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31544sr: Check why some sr_disk_state fields need to be cleared2022-06-17T16:31:17Zteorsr: Check why some sr_disk_state fields need to be clearedSplit off legacy/trac#31240:
teor: When we add fields, how will we make sure we remember to clear them all?
nickm: We don't need to do so in general, the manager will take care of it for us. This is only necessary for derived fields, a...Split off legacy/trac#31240:
teor: When we add fields, how will we make sure we remember to clear them all?
nickm: We don't need to do so in general, the manager will take care of it for us. This is only necessary for derived fields, and fields for which the unit tests are expecting an unusual behavior, IIRC.
nickm: (I can dig deeper here; I forget the exact reason why this function is clearing these, but I think it is because of legacy cruft.)
teor: Yeah let's double-check what's going on here.
https://github.com/nmathewson/tor/pull/3#discussion_r317548828