Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:43:26Zhttps://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/28847Use new subsystems API for initializing the process subsystem2020-06-13T15:35:39ZAlexander Færøyahf@torproject.orgUse new subsystems API for initializing the process subsystemRight now we call `process_init()` in `tor_init()` for the process subsystem. We should refactor this to make use of the new subsystem API.Right now we call `process_init()` in `tor_init()` for the process subsystem. We should refactor this to make use of the new subsystem API.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28846Use K/V parser for handling PT LOG and STATUS messages2020-06-13T15:35:39ZAlexander Færøyahf@torproject.orgUse K/V parser for handling PT LOG and STATUS messagesNick wrote a K/V string parser that is currently available in master. Let's make use of that for handling PT LOG and STATUS messages from PT processes' stdout.Nick wrote a K/V string parser that is currently available in master. Let's make use of that for handling PT LOG and STATUS messages from PT processes' stdout.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28840Allow HeartbeatPeriod of less than 30 minutes in testing Tor networks2020-06-13T15:35:36ZRob JansenAllow HeartbeatPeriod of less than 30 minutes in testing Tor networksThe minimum value currently allowed for the `HeartbeatPeriod` config option is 30 minutes.
It is useful in testing Tor networks (`TestingTorNetwork 1`) to log heartbeat information more often than every 30 minutes.
This is a request to...The minimum value currently allowed for the `HeartbeatPeriod` config option is 30 minutes.
It is useful in testing Tor networks (`TestingTorNetwork 1`) to log heartbeat information more often than every 30 minutes.
This is a request to change Tor so that it does not enforce a minimum value for the `HeartbeatPeriod` in the case that `TestingTorNetwork` is set to 1. Patch attached.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28757Remove deprecated ControlPort commands from GETINFO info/names listing2020-06-13T15:35:19ZTracRemove deprecated ControlPort commands from GETINFO info/names listingIf `GETINFO` commands `status/version/num-concurring` and `status/version/num-versioning` are used in Nyx or `tor-prompt`, Tor writes to its log file:
```
[warn] status/version/num-concurring is deprecated; it no longer gives useful inf...If `GETINFO` commands `status/version/num-concurring` and `status/version/num-versioning` are used in Nyx or `tor-prompt`, Tor writes to its log file:
```
[warn] status/version/num-concurring is deprecated; it no longer gives useful information
[warn] status/version/num-versioning is deprecated; it no longer gives useful information
```
These commands should be removed from interpreter's `/help GETINFO` listing. They are deprecated according to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|control-spec.txt]]:
```
"status/version/num-concurring"
"status/version/num-versioning"
These options are deprecated; they no longer give useful information.
```
[[0.2.0.30](https://blog.torproject.org/tor-02030-released-stable|since)] (more than 10 years):
> o Newly deprecated features:
> - The `status/version/num-versioning` and `status/version/num-concurring` `GETINFO` controller options are no longer useful in the v3 directory protocol: treat them as deprecated, and warn when they're used.
Probably, there are also other deprecated commands in `/help` listing. They should be removed too.
P.S. Initially it was reported in [[comment](https://trac.torproject.org/projects/tor/ticket/28300#comment:4|this)]. teor [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28676#comment:8|recommended]] to create separate ticket.
**Trac**:
**Username**: wagonTor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/28610will WTF-PAD impair bandwidth scanning?2020-06-13T15:34:34Zstarlightwill WTF-PAD impair bandwidth scanning?Is it possible that excess padding data from the WTF-PAD enhancement will impair quality of bandwidth scanner results?
If the answer is yes, should a control channel feature be created to allow disabling WTF-PAD for controller-managed c...Is it possible that excess padding data from the WTF-PAD enhancement will impair quality of bandwidth scanner results?
If the answer is yes, should a control channel feature be created to allow disabling WTF-PAD for controller-managed circuits?
Note in anticipation of a debatable concern: Great quantities of thought have been expended and verbiage has been generated regarding fingerprinting of scanner traffic that can lead to attacks on the network, but my view is this is not as important as producing good network balance. Attracting excess traffic to relays is seemingly of no benefit to the sophisticated adversary and brick-throwing troublemakers can be identified and mitigated. Years of experience with Torflow have not resulted in major incident (AFIK).Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28592Spurious coverity memory leak error in memoize_protover_summary()2020-06-13T15:34:32ZteorSpurious coverity memory leak error in memoize_protover_summary()Coverity says:
```
** CID 1441482: Resource leaks (RESOURCE_LEAK)
/src/core/or/versions.c: 402 in memoize_protover_summary()
________________________________________________________________________________________________________
***...Coverity says:
```
** CID 1441482: Resource leaks (RESOURCE_LEAK)
/src/core/or/versions.c: 402 in memoize_protover_summary()
________________________________________________________________________________________________________
*** CID 1441482: Resource leaks (RESOURCE_LEAK)
/src/core/or/versions.c: 402 in memoize_protover_summary()
396 {
397 if (!protover_summary_map)
398 protover_summary_map = strmap_new();
399
400 if (strmap_size(protover_summary_map) >= MAX_PROTOVER_SUMMARY_MAP_LEN) {
401 protover_summary_cache_free_all();
CID 1441482: Resource leaks (RESOURCE_LEAK)
Overwriting "protover_summary_map" in "protover_summary_map = strmap_new()" leaks the storage that "protover_summary_map" points to.
402 protover_summary_map = strmap_new();
403 }
404
405 const protover_summary_flags_t *cached =
406 strmap_get(protover_summary_map, protocols);
```
But `protover_summary_cache_free_all();` frees protover_summary_map.
cc'ing nickm, because the original fix was his.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28551Tor's Travis should print the python version after installation2020-06-13T15:34:24ZteorTor's Travis should print the python version after installationIf we don't print the actual python version that's running, diagnosing tickets like #28550 is more difficult.
We should print the version for all tests, because many tor tests use python.If we don't print the actual python version that's running, diagnosing tickets like #28550 is more difficult.
We should print the version for all tests, because many tor tests use python.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28257CID 1440805: Memory leak in configured_nameserver_address() due to #219002020-06-13T15:33:33ZteorCID 1440805: Memory leak in configured_nameserver_address() due to #21900```
** CID 1440805: Resource leaks (RESOURCE_LEAK)
/src/feature/relay/dns.c: 1389 in configured_nameserver_address()
________________________________________________________________________________________________________
*** CID 144...```
** CID 1440805: Resource leaks (RESOURCE_LEAK)
/src/feature/relay/dns.c: 1389 in configured_nameserver_address()
________________________________________________________________________________________________________
*** CID 1440805: Resource leaks (RESOURCE_LEAK)
/src/feature/relay/dns.c: 1389 in configured_nameserver_address()
1383 tor_addr_t *tor_addr = tor_malloc(sizeof(tor_addr_t));
1384 if (tor_addr_from_sockaddr(tor_addr,
1385 (const struct sockaddr *)&sa,
1386 NULL) == 0) {
1387 return tor_addr;
1388 }
CID 1440805: Resource leaks (RESOURCE_LEAK)
Variable "tor_addr" going out of scope leaks the storage it points to.
1389 }
1390
1391 return NULL;
1392 }
1393 #endif
```Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28180Signal mechanism from PT processes to Tor2020-06-13T15:33:15ZAlexander Færøyahf@torproject.orgSignal mechanism from PT processes to TorOnce #28179 is done we now have bi-directional communication between the PT process and Tor itself.
We need a method where a PT process can signal to Tor different events that has occurred. This could be things like "Unable to connect t...Once #28179 is done we now have bi-directional communication between the PT process and Tor itself.
We need a method where a PT process can signal to Tor different events that has occurred. This could be things like "Unable to connect to {host}:{port}".
Once we receive these messages from the PT we should expose them via the ControlPort for Tor Browser and friends to be able to act upon them.
This ticket is a tracker ticket for all of this work. Ideally we need to figure out the right way to do this mechanism (is it an update to the PT spec?) and we might also want to update `goptlib` to support this feature to let PT developers use it right away.Tor: 0.4.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/27620Use trunnel to parse and generate SOCKS wire format in tor-resolve2020-06-13T15:31:05Zrl1987Use trunnel to parse and generate SOCKS wire format in tor-resolveTor: 0.4.0.x-finalrl1987rl1987