Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:34:26Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28558Crash in memoize_protover_summary() when cache is full2020-06-13T15:34:26ZNick MathewsonCrash in memoize_protover_summary() when cache is fullIn `memoize_protover_summary()`, after we call `protover_summary_cache_free_all()`, we need to re-create `protover_summary_map`. Otherwise we'll hit an assertion.
Found by OSS-Fuzz; not in any released version.In `memoize_protover_summary()`, after we call `protover_summary_cache_free_all()`, we need to re-create `protover_summary_map`. Otherwise we'll hit an assertion.
Found by OSS-Fuzz; not in any released version.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29109Run stochastic tests faster, log better message when they fail2020-06-13T15:36:52ZNick MathewsonRun stochastic tests faster, log better message when they failI've got a patch to improve the stochastic tests in https://github.com/torproject/tor/pull/656 . I'd like to merge it before the alpha release, if possible to avoid a bunch of wasted cycles and spurious bug reports.I've got a patch to improve the stochastic tests in https://github.com/torproject/tor/pull/656 . I'd like to merge it before the alpha release, if possible to avoid a bunch of wasted cycles and spurious bug reports.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29168Fix TROVE-2019-001 (KIST can write above outbuf highwater mark)2020-06-13T15:37:11ZNick MathewsonFix TROVE-2019-001 (KIST can write above outbuf highwater mark)From the fix in be84ed1a64ed7ce810bd3924fa96c2588b491ef5:
```
KIST works by computing how much should be allowed to write to the kernel for
a given socket, and then it writes that amount to the outbuf.
The problem is tha...From the fix in be84ed1a64ed7ce810bd3924fa96c2588b491ef5:
```
KIST works by computing how much should be allowed to write to the kernel for
a given socket, and then it writes that amount to the outbuf.
The problem is that it could be possible that the outbuf already has lots of
data in it from a previous scheduling round (because the kernel is full/busy
and Tor was not able to flush the outbuf yet). KIST ignores that the outbuf
has been filling (is above its "highwater") and writes more anyway. The end
result is that the outbuf length would exceed INT_MAX, hence causing an
assertion error and a corresponding "Bug()" message to get printed to the
logs.
This commit makes it for KIST to take into account the outbuf length when
computing the available space.
```Tor: 0.4.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29204Inspect circuit queue during padding decisions2020-06-13T15:37:17ZMike PerryInspect circuit queue during padding decisionsWe need to inspect the circuit queue or the channel outbuf in some way during padding decisions. The problem is that if a guard stops reading on a channel, and padding keeps getting scheduled by the middle, it will overflow the circuit q...We need to inspect the circuit queue or the channel outbuf in some way during padding decisions. The problem is that if a guard stops reading on a channel, and padding keeps getting scheduled by the middle, it will overflow the circuit queue and/or outbuf for the channel and eventually oom.
Ideally, we would make our padding decision based on the EWMA values for the circuit rather than just checking if there were queued cells in the outbuf, but at minimum we need some kind of throttling so we don't keep adding cells to an circuit queue or outbuf above a certain length.
We may also want to use the circuit queue activity to update our last packet sent timers..Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29357add an ActiveOnStartup config option2020-06-13T15:37:57ZMark Smithadd an ActiveOnStartup config optionWhen Tor Browser starts tor, it does not make sense to start in dormant mode (the browser is an interactive application which people will typically immediately begin using to surf the web). It would be very helpful if tor had an `ActiveO...When Tor Browser starts tor, it does not make sense to start in dormant mode (the browser is an interactive application which people will typically immediately begin using to surf the web). It would be very helpful if tor had an `ActiveOnStartup` Boolean config option which would ensure that tor starts in active mode.
Related: #29045Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29529util/map_anon_nofork test fails on macOS2020-06-13T15:38:19Zteorutil/map_anon_nofork test fails on macOSI get the following error on macOS:
```
util/map_anon_nofork:
FAIL ../src/test/test_util.c:6209: assert(r OP_LE 0): 1 vs 0
[map_anon_nofork FAILED]
```I get the following error on macOS:
```
util/map_anon_nofork:
FAIL ../src/test/test_util.c:6209: assert(r OP_LE 0): 1 vs 0
[map_anon_nofork FAILED]
```Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29534Regression: map_anon_nofork test is breaking jenkins on some platforms2020-06-13T15:38:21ZNick MathewsonRegression: map_anon_nofork test is breaking jenkins on some platformsThis test from the fast_rng branch is breaking jenkins CI in some cases:
```
17:39:20 util/map_anon_nofork:
17:39:20 FAIL ../tor/src/test/test_util.c:6206: assert((int)r OP_EQ 1): 0 vs 1
17:39:20 [map_anon_nofork FAILED]
```
I sus...This test from the fast_rng branch is breaking jenkins CI in some cases:
```
17:39:20 util/map_anon_nofork:
17:39:20 FAIL ../tor/src/test/test_util.c:6206: assert((int)r OP_EQ 1): 0 vs 1
17:39:20 [map_anon_nofork FAILED]
```
I suspect this is about kernel/header mismatch, but I need to check more closely.
I think we should disable this test in 0.4.0 (since the code is unused) and look for better solutions in 0.4.1.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29538Coverage fails on master2020-06-13T15:38:24ZteorCoverage fails on masterSince about 24 hours ago, coveralls is failing.
The bot isn't posting GitHub comments, and coveralls.io has some builds, with no coverage data.
The last pull request with a bot comment was at 14:39 UTC on 17 Feb:
https://github.com/torp...Since about 24 hours ago, coveralls is failing.
The bot isn't posting GitHub comments, and coveralls.io has some builds, with no coverage data.
The last pull request with a bot comment was at 14:39 UTC on 17 Feb:
https://github.com/torproject/tor/pull/708
Sometimes, the repository isn't found:
```
{u'message': u"Couldn't find a repository matching this job.", u'error': True}
```
https://travis-ci.org/torproject/tor/jobs/495420447#L7333
Sometimes, the coverage is uploaded, but the analysis has no data:
```
{u'url': u'https://coveralls.io/jobs/45356536', u'message': u'Job #3861.6'}
```
https://travis-ci.org/torproject/tor/jobs/495759411#L7330
https://coveralls.io/jobs/45356536
I don't know if this is a coveralls failure, a Travis failure, a GitHub failure, or a change in our code.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31091Bug stracktrace when pluggable transport cannot bind to port2020-06-13T15:43:26Zs7rBug stracktrace when pluggable transport cannot bind to portI have just setup some new obfs4 fast bridges running latest obfs4proxy from yawning / master (locally compiled on my server) and Tor 0.4.2.0-alpha-dev and encountered a bug stack trace when started to try with the pluggable transport li...I have just setup some new obfs4 fast bridges running latest obfs4proxy from yawning / master (locally compiled on my server) and Tor 0.4.2.0-alpha-dev and encountered a bug stack trace when started to try with the pluggable transport listening on a port < 1024. This is well known, which is why even in the wiki page it is recommended and properly documented to use setcap in order to grant permission to the PT executable to bind to lower ports, but shouldn't it just warn and exit, instead of offering all this:
```
Jul 06 05:51:18.000 [warn] Server managed proxy encountered a method error. (obfs4 listen tcp <ipv4>:<port>: bind: permission denied)
Jul 06 05:51:18.000 [warn] Managed proxy at '/usr/local/bin/obfs4proxy' failed the configuration protocol and will be destroyed.
Jul 06 05:51:18.000 [err] tor_assertion_failed_(): Bug: ../src/feature/client/transports.c:1836: managed_proxy_stdout_callback: Assertion mp->conf_state == PT_PROTO_COMPLETED failed; aborting. (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: Assertion mp->conf_state == PT_PROTO_COMPLETED failed in managed_proxy_stdout_callback at ../src/feature/client/transports.c:1836: . Stack trace: (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /usr/bin/tor(log_backtrace_impl+0x47) [0x559a576f5d87] (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x147) [0x559a576f0ed7] (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /usr/bin/tor(+0xd4a89) [0x559a575b8a89] (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /usr/bin/tor(+0x1e4e4b) [0x559a576c8e4b] (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f6f343265a0] (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /usr/bin/tor(do_main_loop+0x105) [0x559a57555ed5] (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /usr/bin/tor(tor_run_main+0x1245) [0x559a57543905] (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /usr/bin/tor(tor_main+0x3a) [0x559a57540cfa] (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /usr/bin/tor(main+0x19) [0x559a57540879] (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f6f32b7b2e1] (on Tor 0.4.2.0-alpha-dev )
Jul 06 05:51:18.000 [err] Bug: /usr/bin/tor(_start+0x2a) [0x559a575408ca] (on Tor 0.4.2.0-alpha-dev )
```
What if it just stopped here:
```
Jul 06 05:51:18.000 [warn] Server managed proxy encountered a method error. (obfs4 listen tcp <ip>:<port>: bind: permission denied)
Jul 06 05:51:18.000 [warn] Managed proxy at '/usr/local/bin/obfs4proxy' failed the configuration protocol and will be destroyed.
```
Or maybe even exit entirely so the operator can know something is really wrong.
Also, I don't know if this is related or not, I will try to make more tests to confirm or infirm this, but under Debian stable the bridges that are not run with setcap don't get a reasonable measured speed. Those with setcap that listen to lower ports have a bw of 2.5 - 3.5 MiB/s and those without setcap have a bw of 12 KiB/s - 70 KiB/s and they are all on the same infrastructure / hardware resources / internet speed. I will do some more digging to confirm this, right now 2 out of 2 obfs4 bridges that were configured without setcap did not get good bandwidth measurement even after 15 days of continuous uptime.Tor: 0.4.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31810Bug: ../src/lib/process/process_unix.c:265: process_unix_exec: Assertion line...2020-06-13T15:45:51ZTracBug: ../src/lib/process/process_unix.c:265: process_unix_exec: Assertion line should be unreached failed; aborting.I am on Debian Buster, x86_64, trying to run Tor (installed from deb.torproject.org).
```
Sep 20 00:18:33 jennis Tor[1481]: Tor 0.4.1.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1c, Zlib 1.2.11, Liblzma 5.2.4, and Libzst...I am on Debian Buster, x86_64, trying to run Tor (installed from deb.torproject.org).
```
Sep 20 00:18:33 jennis Tor[1481]: Tor 0.4.1.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1c, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Sep 20 00:18:33 jennis Tor[1481]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 20 00:18:33 jennis Tor[1481]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Sep 20 00:18:33 jennis Tor[1481]: Read configuration file "/etc/tor/torrc".
Sep 20 00:18:33 jennis Tor[1481]: Opening Socks listener on 127.0.0.1:9050
Sep 20 00:18:33 jennis Tor[1481]: Opened Socks listener on 127.0.0.1:9050
Sep 20 00:18:33 jennis Tor[1481]: Opening DNS listener on 127.0.0.1:53
Sep 20 00:18:33 jennis Tor[1481]: Opened DNS listener on 127.0.0.1:53
Sep 20 00:18:33 jennis Tor[1481]: Opening DNS listener on [::1]:53
Sep 20 00:18:33 jennis Tor[1481]: Opened DNS listener on [::1]:53
Sep 20 00:18:33 jennis Tor[1481]: Opening Transparent pf/netfilter listener on 127.0.0.1:9040
Sep 20 00:18:33 jennis Tor[1481]: Opened Transparent pf/netfilter listener on 127.0.0.1:9040
Sep 20 00:18:33 jennis Tor[1481]: Opening Transparent pf/netfilter listener on [::1]:9040
Sep 20 00:18:33 jennis Tor[1481]: Opened Transparent pf/netfilter listener on [::1]:9040
Sep 20 00:18:33 jennis Tor[1481]: Opening Control listener on 127.0.0.1:9051
Sep 20 00:18:33 jennis Tor[1481]: Opened Control listener on 127.0.0.1:9051
Sep 20 00:18:33 jennis Tor[1481]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Sep 20 00:18:33 jennis Tor[1482]: tor_assertion_failed_(): Bug: ../src/lib/process/process_unix.c:265: process_unix_exec: Assertion line should be unreached failed; aborting. (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: Assertion line should be unreached failed in process_unix_exec at ../src/lib/process/process_unix.c:265: . Stack trace: (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(log_backtrace_impl+0x46) [0x556988adb106] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(tor_assertion_failed_+0x147) [0x556988ad6297] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(process_unix_exec+0x274) [0x556988ab06c4] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(process_exec+0x5b) [0x556988aaea7b] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(pt_configure_remaining_proxies+0x563) [0x5569889a0093] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(set_options+0x18ba) [0x556988a5405a] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(options_init_from_string+0x382) [0x556988a55292] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(options_init_from_torrc+0x38a) [0x556988a5581a] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(tor_init+0x3c7) [0x556988927567] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(tor_run_main+0xb4) [0x556988927e74] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(tor_main+0x3a) [0x55698892638a] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(main+0x19) [0x556988925f49] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f49509c609b] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1482]: Bug: /usr/bin/tor(_start+0x2a) [0x556988925f9a] (on Tor 0.4.1.5 )
Sep 20 00:18:33 jennis Tor[1481]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Sep 20 00:18:33 jennis Tor[1481]: Bootstrapped 0% (starting): Starting
Sep 20 00:18:33 jennis Tor[1481]: Starting with guard context "default"
Sep 20 00:18:33 jennis Tor[1481]: Signaled readiness to systemd
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 5% (conn): Connecting to a relay
Sep 20 00:18:34 jennis Tor[1481]: Opening Control listener on /run/tor/control
Sep 20 00:18:34 jennis Tor[1481]: Opened Control listener on /run/tor/control
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 10% (conn_done): Connected to a relay
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 14% (handshake): Handshaking with a relay
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 15% (handshake_done): Handshake with a relay done
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Sep 20 00:18:34 jennis Tor[1481]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Sep 20 00:18:35 jennis Tor[1481]: Bootstrapped 100% (done): Done
```
**Trac**:
**Username**: ParckwartTor: 0.4.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.org