Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:45:51Zhttps://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.orghttps://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/30614Use MAP_INHERIT_NONE/ZERO if available instead of crashing on assertion failure2020-06-13T15:41:42ZriastradhUse MAP_INHERIT_NONE/ZERO if available instead of crashing on assertion failureOn NetBSD, the way to ask a page range be zero'd or unmapped on fork is `minherit(addr, nbytes, MAP_INHERIT_ZERO)` or `minherit(addr, nbytes, MAP_INHERIT_NONE)`. However,
- map_anon.c does not actually check for or use `MAP_INHERIT_ZER...On NetBSD, the way to ask a page range be zero'd or unmapped on fork is `minherit(addr, nbytes, MAP_INHERIT_ZERO)` or `minherit(addr, nbytes, MAP_INHERIT_NONE)`. However,
- map_anon.c does not actually check for or use `MAP_INHERIT_ZERO` or `MAP_INHERIT_NONE`, so
- `FLAG_NOINHERIT` is undefined, so
- `tor_mmap_anonymous` fails to disinherit the mapping, so
- `crypto_fast_rng_new_from_seed` throws a fit.
```
slow/prob_distr/stochastic_log_logistic: [forking] May 25 03:56:58.091 [err] tor_assertion_failed_(): Bug: src/lib/crypt_ops/crypto_rand_fast.c:184: crypto_fast_rng_new_from_seed: Assertion inherit != INHERIT_RES_KEEP failed; aborting. (on Tor 0.4.1.1-alpha-dev 29955f13e5bc8e61)
May 25 03:56:58.091 [err] Bug: Assertion inherit != INHERIT_RES_KEEP failed in crypto_fast_rng_new_from_seed at src/lib/crypt_ops/crypto_rand_fast.c:184: . (Stack trace not available) (on Tor 0.4.1.1-alpha-dev 29955f13e5bc8e61)
[Lost connection!]
```
The attached patch checks for and uses `MAP_INHERIT_ZERO` and `MAP_INHERIT_NONE`. **However, it does not adjust the code path that gets confused if `tor_mmap_anonymous` fails to disinherit the mapping,** which might be worth doing too, perhaps earlier on by detecting and noisily reporting a lack of support for cutting off the hereditary concentration of wealth, or at least secrets, in society before it's too late.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29897Refactor handle_get_next_bandwidth() to use connection_dir_buf_add()2020-06-13T15:39:50ZteorRefactor handle_get_next_bandwidth() to use connection_dir_buf_add()After #21377 merges, we want to refactor handle_get_next_bandwidth() to use connection_dir_buf_add().
If we backport this refactor to 0.4.0 or earlier, we'll also need #29896 for the connection_dir_buf_add() backport.After #21377 merges, we want to refactor handle_get_next_bandwidth() to use connection_dir_buf_add().
If we backport this refactor to 0.4.0 or earlier, we'll also need #29896 for the connection_dir_buf_add() backport.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29527Division by zero: undefined behaviour in circuitpadding/circuitpadding_sample...2020-06-13T15:38:16ZteorDivision by zero: undefined behaviour in circuitpadding/circuitpadding_sample_distribution testWhen running the tor unit tests on macOS with `--enable-expensive-hardening`, I get the following error:
```
circuitpadding/circuitpadding_sample_distribution: [forking] ../src/lib/math/prob_distr.c:1311:17: runtime error: division by ze...When running the tor unit tests on macOS with `--enable-expensive-hardening`, I get the following error:
```
circuitpadding/circuitpadding_sample_distribution: [forking] ../src/lib/math/prob_distr.c:1311:17: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/lib/math/prob_distr.c:1311:17 in
../src/lib/math/prob_distr.c:1219:49: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/lib/math/prob_distr.c:1219:49 in
OK
```
My full configure command-line is:
```
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 PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig
```Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29500Broken circuitpadding unittests on appveyor2020-06-13T15:40:08ZGeorge KadianakisBroken circuitpadding unittests on appveyorThis x86 appveyor build failed two unittests: https://ci.appveyor.com/project/torproject/tor/builds/22350196/job/457arqlgfgf6b0a3
```
circuitpadding/circuitpadding_tokens: [forking]
FAIL ../src/test/test_circuitpadding.c:1125: assert...This x86 appveyor build failed two unittests: https://ci.appveyor.com/project/torproject/tor/builds/22350196/job/457arqlgfgf6b0a3
```
circuitpadding/circuitpadding_tokens: [forking]
FAIL ../src/test/test_circuitpadding.c:1125: assert(mi->histogram[4] OP_EQ 2): 0 vs 2
[circuitpadding_tokens FAILED]
circuitpadding/circuitpadding_rtt: [forking]
FAIL ../src/test/test_circuitpadding.c:324: assert(relay_side->padding_info[0]->last_received_time_usec OP_NE 0): 0 vs 0
[circuitpadding_rtt FAILED]
```Tor: 0.4.0.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/29391Put git branch-maintenance scripts into scripts directory2020-06-13T15:39:19ZNick MathewsonPut git branch-maintenance scripts into scripts directoryThere are two scripts that David and I have been using to merge stuff to old branches. Now that more people are getting on on the act, let's put them under version control.There are two scripts that David and I have been using to merge stuff to old branches. Now that more people are getting on on the act, let's put them under version control.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29150(Sandbox) Caught a bad syscall attempt (syscall getsockopt)2020-06-13T15:37:08ZTrac(Sandbox) Caught a bad syscall attempt (syscall getsockopt)Starting with the most recent alpha update, 0.4.0.1-alph, Tor crashes when Sandbox is set to 1.
```
Jan 22 20:45:03 kenzie tor[4103]: ============================================================ T= 1548186303
Jan 22 20:45:03 kenzie tor...Starting with the most recent alpha update, 0.4.0.1-alph, Tor crashes when Sandbox is set to 1.
```
Jan 22 20:45:03 kenzie tor[4103]: ============================================================ T= 1548186303
Jan 22 20:45:03 kenzie tor[4103]: (Sandbox) Caught a bad syscall attempt (syscall getsockopt)
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(+0x1e5d2a)[0x556795d78d2a]
Jan 22 20:45:03 kenzie tor[4103]: /lib/x86_64-linux-gnu/libc.so.6(getsockopt+0xa)[0x7f9252a3189a]
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(+0x67d43)[0x556795bfad43]
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(+0x68551)[0x556795bfb551]
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(retry_all_listeners+0x310)[0x556795bfb970]
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(+0x6c99b)[0x556795bff99b]
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(+0x71e33)[0x556795c04e33]
Jan 22 20:45:03 kenzie tor[4103]: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0)[0x7f92541135a
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(do_main_loop+0xbd)[0x556795c044ad]
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(tor_run_main+0x11e5)[0x556795bf17e5]
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(tor_main+0x3a)[0x556795bee96a]
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(main+0x19)[0x556795bee4e9]
Jan 22 20:45:03 kenzie tor[4103]: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f92529682e1]
Jan 22 20:45:03 kenzie tor[4103]: /usr/bin/tor(_start+0x2a)[0x556795bee53a]
```
This is a fresh Debian install:
```
# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.6 (stretch)
Release: 9.6
Codename: stretch
```
**Trac**:
**Username**: pegeTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28984Update dir-spec observed bandwidth to 5 days2020-06-13T15:36:14ZteorUpdate dir-spec observed bandwidth to 5 daysIn #23856 we accidentally updated the observed bandwidth to 5 days from 1 day. It's a good change for privacy, and it doesn't seem to affect load-balancing too much.
So let's update the spec, and review as part of sbws 1.1.In #23856 we accidentally updated the observed bandwidth to 5 days from 1 day. It's a good change for privacy, and it doesn't seem to affect load-balancing too much.
So let's update the spec, and review as part of sbws 1.1.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28976git pre-commit hook that runs 'make check-spaces' and 'make check-changes'2020-06-13T15:36:12Zrl1987git pre-commit hook that runs 'make check-spaces' and 'make check-changes'We already have scripts/maint/pre-push.git-hook which helps preventing fixup commits from ending up in upstream branches. We should also have a pre-commit hook script to prevent creating commits that would fail whitespace and change file...We already have scripts/maint/pre-push.git-hook which helps preventing fixup commits from ending up in upstream branches. We should also have a pre-commit hook script to prevent creating commits that would fail whitespace and change file checkers.Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/28925distinguish PT vs proxy for real in bootstrap tracker2020-06-13T15:39:42ZTaylor Yudistinguish PT vs proxy for real in bootstrap trackerThe bootstrap tracker work in #27167 adds distinctions (in the form of additional bootstrap phases) between connecting directly to a relay vs connecting through a proxy. It also tries to distinguish proxies from PTs.
The changes to do ...The bootstrap tracker work in #27167 adds distinctions (in the form of additional bootstrap phases) between connecting directly to a relay vs connecting through a proxy. It also tries to distinguish proxies from PTs.
The changes to do the distinguishing between PT vs proxy don't work, because `conn->proxy_type` gets set to the protocol type of the underlying protocol that tor uses to talk to the PT locally.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/28920rep_hist_log_link_protocol_counts() only knows about 4 link protocols, but To...2020-06-13T15:35:53Zteorrep_hist_log_link_protocol_counts() only knows about 4 link protocols, but Tor has 5Maybe we should just log all the versions in a loop?Maybe we should just log all the versions in a loop?Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28416The ns consensus isn't explicitly ns in the network-status-version line of fl...2020-06-13T15:34:03ZirlThe ns consensus isn't explicitly ns in the network-status-version line of flavored consensusesPlease review my pull request for torspec:
https://github.com/torproject/torspec/pull/45
tor does not generate ns consensuses that are explicitly labelled as ns
consensuses. This updates the spec to make the flavor portion optional,
an...Please review my pull request for torspec:
https://github.com/torproject/torspec/pull/45
tor does not generate ns consensuses that are explicitly labelled as ns
consensuses. This updates the spec to make the flavor portion optional,
and to allow the assumption to be made that if a flavor is omitted from
the "network-status-version" line then it is "ns".
One "flavour" was also turned into a "flavor" for consistency.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28193Compile-time assertion2020-06-13T15:33:21ZriastradhCompile-time assertionThe enclosed patch implements a `CTASSERT(condition)` macro that, at the top level of a file, causes a compiler error if the constant expression `condition` evaluates to false. This is conciser than
```
#if !condition
#error Condition ...The enclosed patch implements a `CTASSERT(condition)` macro that, at the top level of a file, causes a compiler error if the constant expression `condition` evaluates to false. This is conciser than
```
#if !condition
#error Condition was false.
#endif
```
and applicable in situations that `#if` cannot handle, because `CTASSERT` allows any constant expressions, including, e.g., sizeof, while `#if` is limited to C preprocessor conditional expansion. (Conversely, `CTASSERT` can't be used with `defined(...)`, so it does not subsume `#if`.)
nickm suggested that it should be in src/lib/cc, so I put it there. If you think it should be in a different file, go for it.
The patch uses a couple of different mechanisms to implement it, depending on what the compiler supports:
- If C11 is available, it expands to `_Static_assert(condition, #condition)`. Obviously if you have a C11 compiler this is the best way to do it, because it is most likely to give the best error message.
- If any of `__COUNTER__`, or `__INCLUDE_LEVEL__` and `___LINE__`, or just `__LINE__`, is available, their macro values are expanded and appended to a name `tor_ctassert_` which is typedef'd to an array type with negative length if the condition is false, and positive length if the condition is true. This has zero run-time overhead; the use of `__COUNTER__`, &c., is to attain a unique name, which is guaranteed with `__COUNTER__`, and highly likely with `__INCLUDE_LEVEL__` and `__LINE__`.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28179Handle output from PT processes with the event loop2020-06-13T18:35:29ZAlexander Færøyahf@torproject.orgHandle output from PT processes with the event loopCurrently the output from stdout/stderr of a PT process is only read during the startup of the process. The reading process uses read() on a non-blocking socket, which currently seems to work, but have proved to be flaky.
We should ensu...Currently the output from stdout/stderr of a PT process is only read during the startup of the process. The reading process uses read() on a non-blocking socket, which currently seems to work, but have proved to be flaky.
We should ensure that PT processes' output can be read all the time.
On Windows we cannot attach the pipes to the main loop because of limitations of the `select()` API, so we have to do something slightly worse such as reading from the stdout/stderr handle via a timer as long as the processes are alive.Tor: 0.4.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/27929Consider no longer calling routerlist_remove_old_routers() from check_descrip...2020-06-13T15:32:25Zrl1987Consider no longer calling routerlist_remove_old_routers() from check_descriptor_callback()```
2237 /* Remove dead routers. */
2238 /* XXXX This doesn't belong here, but it was here in the pre-
2239 * XXXX refactoring code. */
2240 routerlist_remove_old_routers();
2241 }
```
We should see if there's better ...```
2237 /* Remove dead routers. */
2238 /* XXXX This doesn't belong here, but it was here in the pre-
2239 * XXXX refactoring code. */
2240 routerlist_remove_old_routers();
2241 }
```
We should see if there's better place to call this function from.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27402stop reporting "internal paths" during bootstrap2020-06-13T15:30:32ZTaylor Yustop reporting "internal paths" during bootstrap`bootstrap_status_to_string()` can report "internal paths" when the consensus actually contains exits, because it's conditional on `router_have_consensus_path()` which checks descriptors. In the cold cache case, there are likely no exis...`bootstrap_status_to_string()` can report "internal paths" when the consensus actually contains exits, because it's conditional on `router_have_consensus_path()` which checks descriptors. In the cold cache case, there are likely no existing descriptors, so tor will give the misleading impression that the consensus lacks exits (when it's actually more likely that it simply hasn't gotten around to downloading enough descriptors yet).
Removing the code that handles these conditions also simplifies `bootstrap_status_to_string()`.
This probably needs a tor-spec update.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/27167track "first" OR_CONN2020-06-13T17:44:18ZTaylor Yutrack "first" OR_CONNRight now the first stages of the "first" OR_CONN get reported as `BOOTSTRAP_STATUS_CONN_DIR` and `BOOTSTRAP_STATUS_HANDSHAKE` (the latter is a special bootstrap phase that gets translated into `BOOTSTRAP_STATUS_HANDSHAKE_DIR` or `BOOTST...Right now the first stages of the "first" OR_CONN get reported as `BOOTSTRAP_STATUS_CONN_DIR` and `BOOTSTRAP_STATUS_HANDSHAKE` (the latter is a special bootstrap phase that gets translated into `BOOTSTRAP_STATUS_HANDSHAKE_DIR` or `BOOTSTRAP_STATUS_HANDSHAKE_OR` depending on how much progress was previously reported. The logic in functions that report these events should be moved up to a new abstraction so lower level code has to track less high-level state.
This also eliminates some logic in `control_event_bootstrap()` that tries to figure out whether a given handshake attempt corresponds to a directory connection or an application circuit connection.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/26973Privcount blinding and encryption: add rustfmt CI check2020-06-13T15:28:52ZteorPrivcount blinding and encryption: add rustfmt CI checkWe should check that rustfmt has been run on the privcount_shamir code in our CI. See:
https://trac.torproject.org/projects/tor/ticket/26955?replyto=3#comment:3We should check that rustfmt has been run on the privcount_shamir code in our CI. See:
https://trac.torproject.org/projects/tor/ticket/26955?replyto=3#comment:3Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/25885count_acceptable_nodes() would be more accurate using node_has_preferred_desc...2020-06-13T15:24:40ZNick Mathewsoncount_acceptable_nodes() would be more accurate using node_has_preferred_descriptor()On a github review for #25691, Teor notes about count_acceptable_nodes():
>I think this code is correct, but it's not obvious:
>
> 1. new_route_len() is the only caller
> 2. new_route_len() will fail if count_acceptable_nodes() is ...On a github review for #25691, Teor notes about count_acceptable_nodes():
>I think this code is correct, but it's not obvious:
>
> 1. new_route_len() is the only caller
> 2. new_route_len() will fail if count_acceptable_nodes() is less than the route length.
> 3. later functions will fail if there is no guard
> 4. later functions will fail if there are not enough subsequent nodes for the rest of the route
>
>So this check can spuriously succeed when we have no guards, or when we have many bridges, and no subsequent nodes. But it can never fail when there are actually enough nodes for the path. So this is just an optimisation to stop us trying to build lots of circuits when we have no descriptors.
>
> We could return the number that pass for_direct_connect = 1 and for_direct_connect = 0, but that seems unnecessarily complicated.
I think that we should probably adjust this function to do the careful count, but it's safe to defer.Tor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.org