Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-11-09T18:16:57Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27813Tor 0.3.4.8 is leaking memory2020-11-09T18:16:57ZTracTor 0.3.4.8 is leaking memoryI upgraded to Tor 0.3.4.8 yesterday and today the process has been killed by the oom killer.
Out of memory: Kill process 1369 (tor) score 338 or sacrifice child.
It seems Tor is leaking memory until there is nothing left.
**Trac**:
...I upgraded to Tor 0.3.4.8 yesterday and today the process has been killed by the oom killer.
Out of memory: Kill process 1369 (tor) score 338 or sacrifice child.
It seems Tor is leaking memory until there is nothing left.
**Trac**:
**Username**: anongTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29819Seccomp: sandbox crash on rt_sigaction with libseccomp 0.2.42020-07-14T22:24:27ZtoralfSeccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4With Sandbox=1 I do get with the new stable Vanilla Linux kernel
```
============================================================ T= 1553016509
(Sandbox) Caught a bad syscall attempt (syscall rt_sigaction)
/usr/bin/tor(+0x1ce5aa)[0x5636a...With Sandbox=1 I do get with the new stable Vanilla Linux kernel
```
============================================================ T= 1553016509
(Sandbox) Caught a bad syscall attempt (syscall rt_sigaction)
/usr/bin/tor(+0x1ce5aa)[0x5636adfa15aa]
/lib64/libpthread.so.0(+0x14125)[0x7f0d99074125]
/lib64/libpthread.so.0(+0x14125)[0x7f0d99074125]
/usr/lib64/libevent-2.1.so.6(evsig_set_handler_+0xeb)[0x7f0d99f4df8b]
/usr/lib64/libevent-2.1.so.6(+0x2c0b6)[0x7f0d99f4e0b6]
/usr/lib64/libevent-2.1.so.6(evmap_signal_add_+0xb5)[0x7f0d99f46b55]
/usr/lib64/libevent-2.1.so.6(event_add_nolock_+0x74e)[0x7f0d99f421ce]
/usr/lib64/libevent-2.1.so.6(event_add+0x3a)[0x7f0d99f423fa]
/usr/bin/tor(handle_signals+0xa7)[0x5636ade2a0c7]
/usr/bin/tor(run_tor_main_loop+0x1a)[0x5636ade2ac8a]
/usr/bin/tor(tor_run_main+0x1045)[0x5636ade2bea5]
/usr/bin/tor(tor_main+0x43)[0x5636ade293e3]
/usr/bin/tor(main+0x19)[0x5636ade28f99]
/lib64/libc.so.6(__libc_start_main+0xe7)[0x7f0d98cb9ae7]
/usr/bin/tor(_start+0x2a)[0x5636ade28fea]
```
An strace narrows it down to
```
write(2, "(Sandbox) Caught a bad syscall a"..., 48(Sandbox) Caught a bad syscall attempt (syscall ) = 48
```Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31837Make test_rebind.py more robust2020-07-14T22:24:20ZteorMake test_rebind.py more robust* actually sleep when waiting for tor to log
* log at debug level when waiting for tor to log
* backslash-replace bad UTF-8 characters in logs
* format control commands as ASCII, tor does not accept UTF-8 control commands
Found during l...* actually sleep when waiting for tor to log
* log at debug level when waiting for tor to log
* backslash-replace bad UTF-8 characters in logs
* format control commands as ASCII, tor does not accept UTF-8 control commands
Found during legacy/trac#30901.Tor: 0.3.5.x-finalteorteorhttps://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/30916assert in dimap_add_entry()2020-07-14T22:24:14ZDavid Gouletdgoulet@torproject.orgassert in dimap_add_entry()From tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2019-June/017402.html
The stack trace is:
```
Jun 18 13:33:31.000 [notice] Bootstrapped 0%: Starting
Jun 18 13:33:32.000 [notice] Starting with guard context "defau...From tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2019-June/017402.html
The stack trace is:
```
Jun 18 13:33:31.000 [notice] Bootstrapped 0%: Starting
Jun 18 13:33:32.000 [notice] Starting with guard context "default"
============================================================ T= 1560854012
INTERNAL ERROR: Raw assertion failed at ../src/lib/ctime/di_ops.c:179: !
old_val/usr/bin/tor(dump_stack_symbols_to_error_fds+0x33)[0x55a17b410943]
/usr/bin/tor(tor_raw_assertion_failed_msg_+0x86)[0x55a17b410fd6]
/usr/bin/tor(dimap_add_entry+0xa0)[0x55a17b411ba0]
/usr/bin/tor(construct_ntor_key_map+0x69)[0x55a17b357969]
/usr/bin/tor(server_onion_keys_new+0x4d)[0x55a17b39f4dd]
/usr/bin/tor(+0x66e27)[0x55a17b287e27]
/usr/bin/tor(threadpool_new+0x18b)[0x55a17b3b3f0b]
/usr/bin/tor(cpu_init+0x9d)[0x55a17b28828d]
/usr/bin/tor(run_tor_main_loop+0x136)[0x55a17b27a496]
/usr/bin/tor(tor_run_main+0x1215)[0x55a17b27b935]
/usr/bin/tor(tor_main+0x3a)[0x55a17b278a8a]
/usr/bin/tor(main+0x19)[0x55a17b278609]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7ffb901ba2e1]
/usr/bin/tor(_start+0x2a)[0x55a17b27865a]
Jun 18 13:33:33.000 [notice] Tor 0.3.5.8 opening log file.
```
It appears that tor tried to add the same value in the `di_digest256_map_t` twice.
Logs indicate 0.3.5.8Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31939log spam: Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf...2020-07-14T22:24:13ZTaylor Yulog spam: Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT_MAX - at_most) failed.Nonfatal assert log spamming as seen in legacy/trac#31036.
```
Jun 26 07:01:30.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT
#_MAX - at_most) failed. (on Tor 0....Nonfatal assert log spamming as seen in legacy/trac#31036.
```
Jun 26 07:01:30.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT
#_MAX - at_most) failed. (on Tor 0.4.0.5 )
```
(I assume the `#` in the middle of `INT_MAX` is a paste/transcription artifact, but then again it might not be.)Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32058mainloop: make periodic events restartable2020-07-14T22:24:09Zteormainloop: make periodic events restartableWhen we shut down tor, we disable periodic events, but leave their enabled flag set to 1.
See this PR for details:
https://github.com/torproject/tor/pull/1397
I'm not sure if this is the best solution, or how far we should backport.When we shut down tor, we disable periodic events, but leave their enabled flag set to 1.
See this PR for details:
https://github.com/torproject/tor/pull/1397
I'm not sure if this is the best solution, or how far we should backport.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31884Define ExecuteBash in the Appveyor error block2020-07-14T22:24:01ZteorDefine ExecuteBash in the Appveyor error blockWhen Appveyor fails before ExecuteBash is defined, it skips straight to the error block. But the error block wants ExecuteBash. So we should define it twice.
Example:
https://ci.appveyor.com/project/nmathewson/tor/build/1.0.850/job/v5mw...When Appveyor fails before ExecuteBash is defined, it skips straight to the error block. But the error block wants ExecuteBash. So we should define it twice.
Example:
https://ci.appveyor.com/project/nmathewson/tor/build/1.0.850/job/v5mws73je9sihmfnTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30344conn_read_callback is called on connections that are marked for closed2020-07-14T22:24:00ZRob Jansenconn_read_callback is called on connections that are marked for closedThere is a bug causing busy loops in Libevent and infinite loops in the Shadow simulator. In my Shadow simulations, I have observed that `conn_read_callback` is getting called on a connection that is marked for close.
This is similar to...There is a bug causing busy loops in Libevent and infinite loops in the Shadow simulator. In my Shadow simulations, I have observed that `conn_read_callback` is getting called on a connection that is marked for close.
This is similar to legacy/trac#5263, and as described there, I believe it is a bug for `conn_read_callback` to be called on sockets that are marked for close.
The bug is problematic in Shadow when the marked connection also wants to flush, but attempting to write the outbuf inside `conn_close_if_marked` fails because the write would block (because the kernel write buffer is already full). Because it still wants to flush, the connection does not get closed, but the connection remains readable causing Libevent to continue looping on `conn_read_callback` until the socket buffer can actually write. This wastes CPU resources in Tor, and causes an infinite loop in Shadow because Shadow's discrete-event time does not advance during this loop.
I found the bug on 0.3.5.8, and it is probably present at least since then.
I think the conn should not be waiting for read events when it is marked. I'm not sure where in the code this assumption is first violated, but the following patch fixed the issue in my Shadow simulations:
```
diff --git a/src/core/mainloop/mainloop.c b/src/core/mainloop/mainloop.c
index 6e2b300..e82c77a 100644
--- a/src/core/mainloop/mainloop.c
+++ b/src/core/mainloop/mainloop.c
@@ -894,6 +894,21 @@ conn_read_callback(evutil_socket_t fd, short event, void *_conn)
}
assert_connection_ok(conn, time(NULL));
+ if (conn->marked_for_close && connection_is_reading(conn)) {
+ /* Libevent says we can read, but we are marked so we will never try
+ * to read again. We will try to close the connection below inside of
+ * close_closeable_connections(), but let's make sure not to cause
+ * Libevent to spin on conn_read_callback() while we wait for the
+ * socket to let us flush to it.*/
+ connection_stop_reading(conn);
+
+ /* Now, if we still have data to flush, then make sure Libevent tells
+ * us when the conn will allow us to write the bytes. */
+ if (connection_wants_to_flush(conn) && !connection_is_writing(conn)) {
+ connection_start_writing(conn);
+ }
+ }
+
if (smartlist_len(closeable_connection_lst))
close_closeable_connections();
}
```Tor: 0.3.5.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/31008Typographical error on tor man pages help command2020-06-29T15:24:29ZAadi BajpaiTypographical error on tor man pages help commandman tor gives the following output as the first command:
```
-h, -help
Display a short help message and exit.
```
Except it's --help and not -help.
-help doesn't work, I found it weird so I tested it just in case and it doesn't.
New ...man tor gives the following output as the first command:
```
-h, -help
Display a short help message and exit.
```
Except it's --help and not -help.
-help doesn't work, I found it weird so I tested it just in case and it doesn't.
New users may get confused if they don't know the -h/--help convention.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3723Report version of bwscanners in votes2020-06-27T14:07:56ZMike PerryReport version of bwscanners in votesEach directory authority should list the git version of the bandwidth scanners in their votes. This ticket has two parts:
1. Edit aggregate.py to output a line with the git commit that it is from.
2. Alter the tor voting to add an "opt...Each directory authority should list the git version of the bandwidth scanners in their votes. This ticket has two parts:
1. Edit aggregate.py to output a line with the git commit that it is from.
2. Alter the tor voting to add an "opt" line or other ignored keyword that lists the version from the bwscan file.
There should be no consensus process for this. We just want a comment in the vote documents, basically.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4700Tor should provide a mechanism for hidden services to differentiate authorize...2020-06-27T14:07:09ZTracTor should provide a mechanism for hidden services to differentiate authorized clients and circuitsTor allows a hidden service to require that clients provide a secret key prior to connecting. Even though hidden services support the use of multiple keys, information mapping the key specified to the specific connection is never exporte...Tor allows a hidden service to require that clients provide a secret key prior to connecting. Even though hidden services support the use of multiple keys, information mapping the key specified to the specific connection is never exported.
**Trac**:
**Username**: katmagicTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8323Missing 'GETINFO md/all'2020-06-27T14:04:41ZDamian JohnsonMissing 'GETINFO md/all'Hi Nick. The control spec has GETINFO options to fetch a microdescriptor via its fingerprint or nickname ('md/id/*' and 'md/name/*') but no method for getting them all (like 'ns/all' or 'desc/all-recent').
Processing all descriptors is ...Hi Nick. The control spec has GETINFO options to fetch a microdescriptor via its fingerprint or nickname ('md/id/*' and 'md/name/*') but no method for getting them all (like 'ns/all' or 'desc/all-recent').
Processing all descriptors is a pretty common need, hence the priority (feel free to lower it if appropriate). In the meantime I'll hack around this in stem by having controller read microdescriptors from the data directory.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/8494Document MaxAdvertisedBandwidth in the bandwidth list spec2020-06-27T14:04:35ZTracDocument MaxAdvertisedBandwidth in the bandwidth list specI've set MaxAdvertisedBandwidth to 100 KB (though RelayBandwidthRate and RelayBandwidthBurst are set to 128 KB and 153 KB, respectively). Accordingly, the relay does not advertise any bandwidth higher than 100 KB. However, the consensus...I've set MaxAdvertisedBandwidth to 100 KB (though RelayBandwidthRate and RelayBandwidthBurst are set to 128 KB and 153 KB, respectively). Accordingly, the relay does not advertise any bandwidth higher than 100 KB. However, the consensus is reporting greater bandwidth:
`valid-after 2013-03-17 01:00:00`
`r PrivateJoker hWF85kNElIsLrCPNTiIkX39mwcg r5DGWEd9ufF4TFXJITuOhw+by6I 2013-03-16 19:18:56 107.197.196.79 443 80`
`s Fast Named Running Stable V2Dir Valid`
`v Tor 0.2.4.11-alpha`
`w Bandwidth=108`
`p reject 1-65535`
The bandwidth line from the descriptor looks like:
```
bandwidth 102400 156672 155648
```
My understanding is that clients use the consensus bandwidth measurement to weigh which paths to choose (correct me if I'm wrong). If this is true, then the consensus should not report bandwidth greater than MaxAdvertisedBandwidth. Perhaps the consensus should never show bandwidth greater than a relay's chosen RelayBandwidthRate?
**Trac**:
**Username**: alphawolfTor: 0.3.5.x-finaljugajugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/13221Misleading error messages about bind_ipv4_only and bind_ipv6_only?2020-06-27T14:02:28ZRoger DingledineMisleading error messages about bind_ipv4_only and bind_ipv6_only?```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with t...```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with the one below it.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15518Tor considers routers in the same IPv6 /16 to be "in the same subnet"2020-06-27T14:01:27ZIsis LovecruftTor considers routers in the same IPv6 /16 to be "in the same subnet"When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses ...When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses
* that we should treat them as being in the same family */
static INLINE int
addrs_in_same_network_family(const tor_addr_t *a1,
const tor_addr_t *a2)
{
return 0 == tor_addr_compare_masked(a1, a2, 16, CMP_SEMANTIC);
}
```
to determine if an address is in the same family. For an example IPv6 address, `2001:1234::0:1`, its /16 representation is `2001::/16`, meaning that `2001:ffff::` would be in the same family. A `\16` for IPv6 is _huge_, particularly considering that [only one-eighth of all IPv6 space is currently allocated for use on the internet](https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml) (`2000::/3`). For the path selection code, using `/16` essentially means that no two IPv6 routers in the same country (or possibly even continent) will be in the same path, and might possibly provide extremely increased chance of selection to routers in weird/rare IPv6 subnets.
For a related ticket, see legacy/trac#15517 governing how BridgeDB's version of `EnforceDistinctSubnets` will work for IPv6. (In that ticket, I proposed using IPv6 `/32`s, since that is the [minimum ARIN IPv6 subnet allocation for a LIR](https://www.arin.net/resources/request/ipv6_initial_assign.html).Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/17873replacing 0.0.0.0 listeners at runtime fails2020-06-27T13:59:56Zcypherpunksreplacing 0.0.0.0 listeners at runtime failsI had DNSPort 0.0.0.0:53 set. Some jerks on the internet started flooding me with DNS requests so I reconfigured tor to only have the DNSPort on my LAN interface. I sent tor a HUP to reload the config, and it exited because it tried to b...I had DNSPort 0.0.0.0:53 set. Some jerks on the internet started flooding me with DNS requests so I reconfigured tor to only have the DNSPort on my LAN interface. I sent tor a HUP to reload the config, and it exited because it tried to bind the new listener before unbinding the old one:
```
Dec 16 16:19:51.000 [notice] Opening DNS listener on 172.16.0.1:53
Dec 16 16:19:51.000 [warn] Could not bind to 172.16.0.1:53: Permission denied
Dec 16 16:19:51.000 [notice] Closing no-longer-configured DNS listener on 0.0.0.0:53
Dec 16 16:19:51.000 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Dec 16 16:19:51.000 [err] Reading config failed--see warnings above. For usage, try -h.
Dec 16 16:19:51.000 [warn] Restart failed (config error?). Exiting.
```Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/19506Tool to inspect id signing certs2020-06-27T13:58:41Zweasel (Peter Palfrader)Tool to inspect id signing certsThere is no tool to figure out what is inside an ed25519_signing_cert file.
For monitoring purposes it's important we have a way to learn something like expiration date.There is no tool to figure out what is inside an ed25519_signing_cert file.
For monitoring purposes it's important we have a way to learn something like expiration date.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/19566SR: Use BUG() instead of tor_assert() when we can2020-06-27T13:58:37ZDavid Gouletdgoulet@torproject.orgSR: Use BUG() instead of tor_assert() when we canExample:
```
tor_assert(sr_state_get_phase() == SR_PHASE_REVEAL);
```
Should be replaced by:
```
if (BUG(sr_state_get_phase() != SR_PHASE_REVEAL))
return;
```
The idea is to not kill the dirauth if this happens but still scream very...Example:
```
tor_assert(sr_state_get_phase() == SR_PHASE_REVEAL);
```
Should be replaced by:
```
if (BUG(sr_state_get_phase() != SR_PHASE_REVEAL))
return;
```
The idea is to not kill the dirauth if this happens but still scream very loudly. Few other places in the SR subsystem can be found.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/20424Remove --enable-openbsd-malloc (Tor maxes CPU when --enable-openbsd-malloc is...2020-06-27T13:58:01ZTracRemove --enable-openbsd-malloc (Tor maxes CPU when --enable-openbsd-malloc is used)When tor is built with --enable-openbsd-malloc running 'make test' consumes 100% of the CPU. Attaching a debugger to the process shows it looping forever in calloc (src/ext/OpenBSD_malloc_Linux.c). Changing from -O2 to -O3 (or -O1) in th...When tor is built with --enable-openbsd-malloc running 'make test' consumes 100% of the CPU. Attaching a debugger to the process shows it looping forever in calloc (src/ext/OpenBSD_malloc_Linux.c). Changing from -O2 to -O3 (or -O1) in the Makefile "fixes" (as in the tests run) the issues so it seems to be a compiler bug.
Some more details:
Debian testing, x86_64
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-6' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20161010 (Debian 6.2.0-6)
I've attached the output of objdump for the failing and working object files, but I'm too stupid to debug it any further, so hopefully someone more intelligent can.
**Trac**:
**Username**: icanhasaccountTor: 0.3.5.x-final