Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:48:36Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32613Simple tests for checkSpaces.pl2020-06-13T15:48:36ZNick MathewsonSimple tests for checkSpaces.plI'd like to replace checkSpaces.pl with a python solution. But before we can even think about that, we ought to have tests.
Our existing codebase works well to detect false positives in checkSpaces.pl, so for now, we should just check ...I'd like to replace checkSpaces.pl with a python solution. But before we can even think about that, we ought to have tests.
Our existing codebase works well to detect false positives in checkSpaces.pl, so for now, we should just check for false negatives.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32611Use J= to parallelise coccinelle2020-06-13T15:48:35ZteorUse J= to parallelise coccinelleIf we feed coccinelle all our files at the same time, and use the J=N variable, we can parallelise the (slow) parsing checks.
This isn't usually a big deal for the commit hook or makefile, because the commit hook only checks changed fil...If we feed coccinelle all our files at the same time, and use the J=N variable, we can parallelise the (slow) parsing checks.
This isn't usually a big deal for the commit hook or makefile, because the commit hook only checks changed files, and the Makefile already runs "make check" in parallel.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32610Add macro spacing checks to "make check-spaces"2020-06-13T15:48:35ZteorAdd macro spacing checks to "make check-spaces"Let's check macro spacing like we check other keyword spacing.
And let's check for `else {`.Let's check macro spacing like we check other keyword spacing.
And let's check for `else {`.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32609Improve practracker unit tests, and run them in "make check" and pre-commit2020-06-13T15:48:34ZteorImprove practracker unit tests, and run them in "make check" and pre-commitTor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32608Make configure script only accept python32020-06-13T15:48:33ZNick MathewsonMake configure script only accept python3Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32604Add HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive2020-06-13T15:48:33ZTracAdd HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directiveAdd HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive to export rendezvous point information and instance ID along with circuit ID
**Trac**:
**Username**: moonsikparkAdd HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive to export rendezvous point information and instance ID along with circuit ID
**Trac**:
**Username**: moonsikparkTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32594Fix CID 1455953: Resource leaks in #324272020-06-13T15:48:31ZteorFix CID 1455953: Resource leaks in #32427```
** CID 1455953: Resource leaks (RESOURCE_LEAK)
/src/app/config/config.c: 1983 in options_act_reversible()
________________________________________________________________________________________________________
*** CID 1455953: ...```
** CID 1455953: Resource leaks (RESOURCE_LEAK)
/src/app/config/config.c: 1983 in options_act_reversible()
________________________________________________________________________________________________________
*** CID 1455953: Resource leaks (RESOURCE_LEAK)
/src/app/config/config.c: 1983 in options_act_reversible()
1977 tor_assert(*msg);
1978
1979 options_rollback_log_transaction(log_transaction);
1980 options_rollback_listener_transaction(listener_transaction);
1981
1982 done:
CID 1455953: Resource leaks (RESOURCE_LEAK)
Variable "listener_transaction" going out of scope leaks the storage it points to.
1983 return r;
1984 }
1985
1986 /** If we need to have a GEOIP ip-to-country map to run with our configured
1987 * options, return 1 and set *<b>reason_out</b> to a description of why. */
1988 int
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32588Setting ORPort [ipv6]:auto mistakenly advertises port 942020-06-13T15:49:47ZRoger DingledineSetting ORPort [ipv6]:auto mistakenly advertises port 94Start your Tor with
```
ORPort 9001
ORPort [2a01:238:43e4:2b00:ae5a:a980:1f63:cc5e]:auto nolisten
DirPort 9030
```
and let it start up. Then go to http://127.0.0.1:9030/tor/server/authority and check out how it has the line
```
or-addres...Start your Tor with
```
ORPort 9001
ORPort [2a01:238:43e4:2b00:ae5a:a980:1f63:cc5e]:auto nolisten
DirPort 9030
```
and let it start up. Then go to http://127.0.0.1:9030/tor/server/authority and check out how it has the line
```
or-address [2a01:238:43e4:2b00:ae5a:a980:1f63:cc5e]:94
```
First: How did it pick that number? It's a weird choice for a port.
Second: If this is actually your ipv6 address, you can leave out the nolisten, and that's where things get interesting. Your logs will say something like
```
Nov 24 01:53:42 v4 tor[10988]: Nov 24 01:53:42.001 [notice] Opening OR listener on [2a01:238:43e4:2b00:ae5a:a980:1f63:cc5e]:0
Nov 24 01:53:42 v4 tor[10988]: Nov 24 01:53:42.002 [notice] Opened OR listener on [2a01:238:43e4:2b00:ae5a:a980:1f63:cc5e]:41535
```
but then your descriptor will still say :94.
This is happening right now to relay "Testbit": they have set :auto for their ipv6 address in their ORPort, they get the above line about how it's opened on port 41535, and yet their descriptor says it's on port 94.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32584rename_c_identifier.py: bug when doing only one replacement.2020-06-13T15:48:29ZNick Mathewsonrename_c_identifier.py: bug when doing only one replacement.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32581Turn on clang's -Wtype-safety to detect fnctl() and ioctl() errors2020-06-13T15:48:28ZteorTurn on clang's -Wtype-safety to detect fnctl() and ioctl() errorsSee:
https://clang.llvm.org/docs/AttributeReference.html#type-safety-checkingSee:
https://clang.llvm.org/docs/AttributeReference.html#type-safety-checkingTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32580Use clang's enum_extensibility attribute to check enum values2020-06-13T15:48:28ZteorUse clang's enum_extensibility attribute to check enum valuesWe could avoid constructing bad enum values using enum_extensibility:
https://clang.llvm.org/docs/AttributeReference.html#enum-extensibilityWe could avoid constructing bad enum values using enum_extensibility:
https://clang.llvm.org/docs/AttributeReference.html#enum-extensibilityTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32579Use clang's -Wimplicit-fallthrough and fallthrough attribute on case statements2020-06-13T15:48:28ZteorUse clang's -Wimplicit-fallthrough and fallthrough attribute on case statementsWe can avoid accidental fallthroughs using clang's -Wimplicit-fallthrough.
https://clang.llvm.org/docs/AttributeReference.html#fallthroughWe can avoid accidental fallthroughs using clang's -Wimplicit-fallthrough.
https://clang.llvm.org/docs/AttributeReference.html#fallthroughTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32575CID 1455953: Resource leak in options_act_reversible()2020-06-13T15:48:27ZNick MathewsonCID 1455953: Resource leak in options_act_reversible()```
*** CID 1455953: Resource leaks (RESOURCE_LEAK)
/src/app/config/config.c: 1983 in options_act_reversible()
1977 tor_assert(*msg);
1978
1979 options_rollback_log_transaction(log_transaction);
1980 options_rol...```
*** CID 1455953: Resource leaks (RESOURCE_LEAK)
/src/app/config/config.c: 1983 in options_act_reversible()
1977 tor_assert(*msg);
1978
1979 options_rollback_log_transaction(log_transaction);
1980 options_rollback_listener_transaction(listener_transaction);
1981
1982 done:
>>> CID 1455953: Resource leaks (RESOURCE_LEAK)
>>> Variable "listener_transaction" going out of scope leaks the storage it points to.
1983 return r;
1984 }
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32564Assertion pol->magic failed2020-06-13T15:51:22ZTracAssertion pol->magic failedGuard relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 crashed with the following log:
```
Nov 21 00:18:01.000 [err] tor_assertion_failed_(): Bug: ../src/core/or/circuitmux_ewma.c:165: TO_EWMA_POL_CIRC_DATA: Assertion pol->magic == 0x761e7...Guard relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 crashed with the following log:
```
Nov 21 00:18:01.000 [err] tor_assertion_failed_(): Bug: ../src/core/or/circuitmux_ewma.c:165: TO_EWMA_POL_CIRC_DATA: Assertion pol->magic == 0x761e7747U failed; aborting. (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: Assertion pol->magic == 0x761e7747U failed in TO_EWMA_POL_CIRC_DATA at ../src/core/or/circuitmux_ewma.c:165: . Stack trace: (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(log_backtrace_impl+0x47) [0x55d5e9f968e7] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x147) [0x55d5e9f919c7] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0x8fe84) [0x55d5e9e14e84] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0xb839f) [0x55d5e9e3d39f] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x29a) [0x55d5e9e419fa] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(command_process_cell+0x2fc) [0x55d5e9e23a1c] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(channel_tls_handle_cell+0x333) [0x55d5e9e030d3] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0xa773f) [0x55d5e9e2c73f] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(connection_handle_read+0x990) [0x55d5e9df0500] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0x707ee) [0x55d5e9df57ee] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fb82bb5f5a0] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(do_main_loop+0x105) [0x55d5e9df6b25] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(tor_run_main+0x1225) [0x55d5e9de4545] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(tor_main+0x3a) [0x55d5e9de193a] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(main+0x19) [0x55d5e9de14b9] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fb82a3b32e1] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(_start+0x2a) [0x55d5e9de150a] (on Tor 0.4.1.6 )
```
After the relay automatically restarted the log had the following warning:
```
Nov 21 00:18:07.000 [warn] Incorrect ed25519 signature(s)
```
Possibly the same as #16423 according to Nick.
Relay is one of two relays running on a Debian box. Memory and CPU usage are normal.
Odd things about the relay:
* 1. About a week ago I had log entries (rotated unfortunately) to the effect of not being able to apply consensus diffs (wrong hash) and eventually "no longer serving directory info to clients"
* 2. Lately the two relays has seen an upswing in traffic. Sometimes their combined BW hits my ISPs ceiling.
* 3. Over time the memory usages of the relays grows. Initially they are around 700MB. Once they use most of the RAM (4GB) I reboot the machine. When the assert happened the RAM usage was nowhere near that.
* 4. I run my home brewed monitoring software that uses "SETEVENT BW" and calls "GETINFO orconn-status ns/id/<fingerprint> status/fresh-relay-descs" every 10 minutes.
**Trac**:
**Username**: LogformeTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32563Merge HSv3 spec fixes we found during onionbalance creation2020-06-13T15:48:25ZGeorge KadianakisMerge HSv3 spec fixes we found during onionbalance creationThere are a few issues with the v3 spec that we found out as we were implementing onionbalance. We should merge them.
Examples:
- https://github.com/asn-d6/stem/pull/2#discussion_r348847261
- The MAC description in the descriptor encryp...There are a few issues with the v3 spec that we found out as we were implementing onionbalance. We should merge them.
Examples:
- https://github.com/asn-d6/stem/pull/2#discussion_r348847261
- The MAC description in the descriptor encryption is wrong.Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/32562Allow ONION_CLIENT_AUTH_ADD credentials to be made permanent2020-06-13T15:48:25ZGeorge KadianakisAllow ONION_CLIENT_AUTH_ADD credentials to be made permanentThe Permanent flag of ONION_CLIENT_AUTH_ADD is not implemented yet.The Permanent flag of ONION_CLIENT_AUTH_ADD is not implemented yet.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32559Travis: run chutney with clang for better diagnostics2020-06-13T15:48:24ZteorTravis: run chutney with clang for better diagnosticsIn #32555 and #32427, we discovered that clang picks up some memory errors, but gcc does not.In #32555 and #32427, we discovered that clang picks up some memory errors, but gcc does not.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32555Memory leak on or_options_t?2020-06-13T15:48:23ZNick MathewsonMemory leak on or_options_t?When I build with --enable-fragile-hardening and CC=clang, and run test-network, I get a pile of memory leaks, related to the options object. Time to investigate.When I build with --enable-fragile-hardening and CC=clang, and run test-network, I get a pile of memory leaks, related to the options object. Time to investigate.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32546hs-v3: Report invalid onion address SOCKS5 extended error code2020-06-16T01:10:52ZDavid Gouletdgoulet@torproject.orghs-v3: Report invalid onion address SOCKS5 extended error codeFrom prop304, continuing on after #30382, add a new error code to indicate invalid address.
This is the little-t tor side of #30022.From prop304, continuing on after #30382, add a new error code to indicate invalid address.
This is the little-t tor side of #30022.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32543spec: Merge prop304 into torspec.git in socks-extensions.txt2020-06-13T15:48:21ZDavid Gouletdgoulet@torproject.orgspec: Merge prop304 into torspec.git in socks-extensions.txt#30382 has been merged upstream, prop304 needs to be put in socks-extensions.txt and then `Closed`.#30382 has been merged upstream, prop304 needs to be put in socks-extensions.txt and then `Closed`.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org