The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-16T14:34:35Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17739Refactor clock skew warning code to avoid duplication2021-09-16T14:34:35ZteorRefactor clock skew warning code to avoid duplicationThe following functions contain very similar clock skew code:
* connection_dir_client_reached_eof
* channel_tls_process_netinfo_cell
* or_state_load
We should unify this code to reduce redundancy and increase consistency.The following functions contain very similar clock skew code:
* connection_dir_client_reached_eof
* channel_tls_process_netinfo_cell
* or_state_load
We should unify this code to reduce redundancy and increase consistency.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17740Unit Tests for Recent Consensuses2020-07-27T18:15:32ZteorUnit Tests for Recent ConsensusesIt would be great to have unit tests for the functions that return a recent consensus:
Mock:
* networkstatus_get_latest_consensus_by_flavor
Test:
* networkstatus_get_latest_consensus
* networkstatus_get_reasonably_live_consensus
* netw...It would be great to have unit tests for the functions that return a recent consensus:
Mock:
* networkstatus_get_latest_consensus_by_flavor
Test:
* networkstatus_get_latest_consensus
* networkstatus_get_reasonably_live_consensus
* networkstatus_consensus_is_boostrappingTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17744Add quotes when comparing strings in configure script2020-06-27T14:00:07ZcypherpunksAdd quotes when comparing strings in configure scriptIn ticket:16651#comment:28 missing quotes caused parsing errors. The configure script still contains instances of strings being compared without quotes. AFAIK these remaining cases do not cause any problems right now but it is better to ...In ticket:16651#comment:28 missing quotes caused parsing errors. The configure script still contains instances of strings being compared without quotes. AFAIK these remaining cases do not cause any problems right now but it is better to fix them now to avoid problems in the future.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17751Use router_get_my_routerinfo() rather than desc_routerinfo2020-06-27T14:00:06ZteorUse router_get_my_routerinfo() rather than desc_routerinfoThe following functions use desc_routerinfo where they could use router_get_my_routerinfo():
* check_descriptor_ipaddress_changed
* router_compare_to_my_exit_policy
* router_my_exit_policy_is_reject_star
* router_get_my_descriptor
* chec...The following functions use desc_routerinfo where they could use router_get_my_routerinfo():
* check_descriptor_ipaddress_changed
* router_compare_to_my_exit_policy
* router_my_exit_policy_is_reject_star
* router_get_my_descriptor
* check_descriptor_bandwidth_changed
This could cause issues if desc_routerinfo needs to be rebuilt, because some of these functions don't call router_get_my_routerinfo() first.
Others have comments about desc_routerinfo that might need to be updated:
* dirserv_get_routerdescs
* router_compare_to_my_exit_policy
* Also change "IPv6 and IPv6 entries" to "IPv4 and IPv6 entries"Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17758inaccurate log line (-1 out of 360)2020-06-27T14:00:06ZRoger Dingledineinaccurate log line (-1 out of 360)I ran out of disk space, and saw this in my logs:
```
Dec 05 03:08:36.663 [warn] Couldn't dump microdescriptor (wrote -1 out of 360): No space left on device
```
Did it really un-write one of the bytes? :)I ran out of disk space, and saw this in my logs:
```
Dec 05 03:08:36.663 [warn] Couldn't dump microdescriptor (wrote -1 out of 360): No space left on device
```
Did it really un-write one of the bytes? :)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17779Memory leak in routerkeys.c2020-06-27T14:00:04ZcypherpunksMemory leak in routerkeys.cThe `rsa_ed_crosscert` variable is assigned a cross-certification object in the `load_ed_keys` function but is never freed. Secondly, the variable is only used by the `get_master_rsa_crosscert` function which, in turn, is not used by the...The `rsa_ed_crosscert` variable is assigned a cross-certification object in the `load_ed_keys` function but is never freed. Secondly, the variable is only used by the `get_master_rsa_crosscert` function which, in turn, is not used by the current code base.
My suggestion is to remove the `rsa_ed_crosscert` variable and the `get_master_rsa_crosscert` function to fix the memory leak (unless they have some future use-case).
The variable and function were added in 3bee74c6d115131f4850a07a5c12db21ae6f3193.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17782Relays may publish descriptors with incorrect IP address2020-07-27T18:20:10ZfkRelays may publish descriptors with incorrect IP addressI suspect that the following bug could be used by malicious directories
to cause relays that rely on directories to get their external IP address
to publish bogus descriptors which should reduce their chances to make
it into the next con...I suspect that the following bug could be used by malicious directories
to cause relays that rely on directories to get their external IP address
to publish bogus descriptors which should reduce their chances to make
it into the next consensus.
I privately reported the issue yesterday and it has been decided
that there's no need to keep it secret.
The relay elektrobier2 (3D615DEF97F387631F50201FAFA6E7B67FDF3FEF)
is running in an ElectroBSD jail with:
ORPort 9001 NoAdvertise
ORPort 443 NoListen
Tor binds to 127.0.1.1:9001, pf is forwarding incoming traffic
from 95.211.138.7:443 and nat'ing outgoing traffic:
```
[fk@elektrobier ~]$ jls | grep elektrobier2
5 127.0.1.1 elektrobier2 /usr/jails/elektrobier2
[fk@elektrobier ~]$ sudo pfctl -sn -P | grep 127.0.1.1
nat on bge0 inet from 127.0.1.1 to any -> 95.211.138.7
rdr pass on bge0 inet proto tcp from any to 95.211.138.7 port = 443 -> 127.0.1.1 port 9001
```
This used to work fine and Tor correctly detected the external IP
address when the system only had one external IPv4 address.
After the system got a second external IP address, pf was briefly
nat'ing outgoing traffic using both external IPv4 addresses while
still only forwarding incoming traffic from 95.211.138.7:443 to Tor.
This resulted in undesirable behaviour:
```
Dec 01 18:34:58.337 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 18:34:58.550 [notice] {GENERAL} Tor has successfully opened a circuit. Looks like client functionality is working.
Dec 01 18:34:58.550 [notice] {CONTROL} Bootstrapped 100%: Done
Dec 01 18:36:45.949 [notice] {CONTROL} New control connection opened from 127.0.1.1.
Dec 01 18:41:01.459 [notice] {OR} Performing bandwidth self-test...done.
Dec 01 18:55:26.206 [notice] {GENERAL} Our IP Address has changed from 95.211.138.51 to 95.211.138.7; rebuilding descriptor (source: 144.76.92.46).
Dec 01 18:55:26.274 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 19:55:29.426 [notice] {GENERAL} Our IP Address has changed from 95.211.138.7 to 95.211.138.51; rebuilding descriptor (source: 124.6.36.195).
Dec 01 19:55:30.351 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 20:15:45.001 [notice] {GENERAL} Our IP Address has changed from 95.211.138.51 to 95.211.138.7; rebuilding descriptor (source: 146.0.32.144).
Dec 01 20:15:47.988 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 20:16:35.027 [notice] {GENERAL} Our IP Address has changed from 95.211.138.7 to 95.211.138.51; rebuilding descriptor (source: 171.25.193.9).
Dec 01 20:16:35.367 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 20:36:05.053 [notice] {GENERAL} Our IP Address has changed from 95.211.138.51 to 95.211.138.7; rebuilding descriptor (source: 212.51.155.40).
Dec 01 20:36:05.098 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 20:56:25.006 [notice] {GENERAL} Our IP Address has changed from 95.211.138.7 to 95.211.138.51; rebuilding descriptor (source: 154.46.204.125).
Dec 01 20:56:25.254 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 21:15:33.282 [notice] {GENERAL} Our IP Address has changed from 95.211.138.51 to 95.211.138.7; rebuilding descriptor (source: 50.7.184.58).
Dec 01 21:15:33.756 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 21:16:34.015 [notice] {GENERAL} Our IP Address has changed from 95.211.138.7 to 95.211.138.51; rebuilding descriptor (source: 193.23.244.244).
Dec 01 21:16:34.033 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 21:17:35.514 [notice] {GENERAL} Our IP Address has changed from 95.211.138.51 to 95.211.138.7; rebuilding descriptor (source: 208.83.223.34).
Dec 01 21:17:35.710 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 21:56:14.079 [notice] {GENERAL} Our IP Address has changed from 95.211.138.7 to 95.211.138.51; rebuilding descriptor (source: 89.46.101.181).
Dec 01 21:56:14.414 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 01 21:57:25.355 [notice] {GENERAL} Our IP Address has changed from 95.211.138.51 to 95.211.138.7; rebuilding descriptor (source: 185.11.136.211).
Dec 01 21:57:25.409 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
```
The messages seem to imply that Tor is only publishing the IP address
after verifying that it can be reached through it.
Unless I misinterpret the code, it only verified that it got incoming traffic
on its ORPort, though, and in this case all the traffic came through
95.211.138.7:443 while traffic to 95.211.138.51:443 was not forwarded to
this relay and not part of the reachability test.
Therefore I suspect that the contacted directories could trick the relay
into publishing any IP address in which case the relay could fall
out of the next consensus.
BTW, after noticing the issue I changed the pf configuration to use a fixed
IP address mapping when nat'ing Tor traffic, but surprisingly this did
not completely workaround the problem for this relay and just reduced
the number of times address changes were detected. Even days later I got:
```
Dec 07 07:00:00.725 [notice] {ACCT} Configured hibernation. This interval began at 2015-12-07 07:00:00; the scheduled wake-up time was 2015-12-07 07:00:00; we expect to exhaust our quota for this interval around 2015-12-08 07:00:00; the next interval begins at 2015-12-08 07:00:00 (all times local)
Dec 07 10:23:30.725 [notice] {GENERAL} Our IP Address has changed from 95.211.138.7 to 95.211.138.51; rebuilding descriptor (source: 62.210.71.167).
Dec 07 10:23:30.841 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 07 10:23:39.912 [notice] {OR} Performing bandwidth self-test...done.
Dec 07 10:43:52.145 [notice] {GENERAL} Our IP Address has changed from 95.211.138.51 to 95.211.138.7; rebuilding descriptor (source: 104.131.136.238).
Dec 07 10:43:52.737 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 07 11:28:43.311 [notice] {GENERAL} Our IP Address has changed from 95.211.138.7 to 95.211.138.51; rebuilding descriptor (source: 62.210.142.39).
Dec 07 11:28:43.734 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 07 11:45:51.148 [notice] {CIRC} No circuits are opened. Relaxed timeout for circuit 665 (a General-purpose client 1-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. 2 guards are live.
Dec 07 12:05:10.598 [notice] {GENERAL} Our IP Address has changed from 95.211.138.51 to 95.211.138.7; rebuilding descriptor (source: 198.100.155.91).
Dec 07 12:05:10.905 [notice] {OR} Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 07 12:34:54.194 [notice] {HEARTBEAT} Heartbeat: Tor's uptime is 0:29 hours, with 2018 circuits open. I've sent 592.36 GB and received 591.16 GB.
Dec 07 12:34:54.205 [notice] {HEARTBEAT} Heartbeat: Accounting enabled. Sent: 41.50 GB / 1000.00 GB, Received: 41.41 GB / 1000.00 GB. The current accounting interval ends on 2015-12-08 07:00:00, in 18:25 hours.
Dec 07 12:34:54.205 [notice] {HEARTBEAT} Circuit handshake stats since last time: 30713/30713 TAP, 64172/64172 NTor.
Dec 07 12:34:54.205 [notice] {HEARTBEAT} Since startup, we have initiated 0 v1 connections, 3 v2 connections, 10 v3 connections, and 233777 v4 connections; and received 402 v1 connections, 112 v2 connections, 3 v3 connections, and 179033 v4 connections.
```
I finally added "Address 95.211.138.7" to see if this helps, but for the relay
polizei-erziehung (5CE3AD8AD04ADE66C0037A3CF5F7F7A40D48A20B) which is running
in another jail on the same system this wasn't necessary and I have no idea why.
While both relays are running 0.2.7.4-rc, other releases should be affected as well.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17793Inconsistent function comment cache_failure_intro_lookup2021-07-22T16:25:32ZcypherpunksInconsistent function comment cache_failure_intro_lookupThe `cache_failure_intro_lookup` function comment mentions that the `intro_entry` remains untouched when no entry is found in the rend failure cache. Yet the `intro_entry` variable is set to `NULL` right from the start.
We should find o...The `cache_failure_intro_lookup` function comment mentions that the `intro_entry` remains untouched when no entry is found in the rend failure cache. Yet the `intro_entry` variable is set to `NULL` right from the start.
We should find out if code depends on this behavior and make the behavior and comment consistent.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17800Tor Unit Tests should TT_FORK before initialising global PRNG state2020-07-27T18:23:23ZteorTor Unit Tests should TT_FORK before initialising global PRNG stateTor unit tests are meant to TT_FORK before changing any global process state that can't be reverted.
In legacy/trac#17789, we discovered that one or more tests initialise the OpenSSL CSPRNG without forking first. (This can't be undone.)...Tor unit tests are meant to TT_FORK before changing any global process state that can't be reverted.
In legacy/trac#17789, we discovered that one or more tests initialise the OpenSSL CSPRNG without forking first. (This can't be undone.)
While this isn't likely to cause any issues, (legacy/trac#17789 was marked as wontfix for other reasons), it would be nice to fix it eventually for correctness.
One way to do this is:
* initialise a static variable to 0.
* set it to 1 just after fork()ing via TT_FORK.
* tor_assert() that it's 1 in functions that irreversibly modify global test process state, if TOR_UNIT_TESTS is defined:
* crypto_early_init(), which seeds the OpenSSL CSPRNG,
* (I'm sure many other init functions do similar things)
* mark the tests that assert as TT_FORK
Marked as Low/Minor because this doesn't currently cause any issues, but if tests start failing due to interactions with previous global state, we should look at it again.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17806Make onion queues rational, combine with workqueue logic.2022-10-11T23:40:46ZNick MathewsonMake onion queues rational, combine with workqueue logic.Right now we have two queues for onions: one before we hand things over to the workqueue, and the workqueue itself.
Soon we'll have a client-side queue for onions, plus the workqueue. (legacy/trac#13737)
Having these extra queues is mi...Right now we have two queues for onions: one before we hand things over to the workqueue, and the workqueue itself.
Soon we'll have a client-side queue for onions, plus the workqueue. (legacy/trac#13737)
Having these extra queues is mildly helpful, since it lets us implement queueing rules more complicated than "first in first out", but it makes our code more complex. Perhaps we should abstract the priority rules and make the workqueue code the only queue we need to care about.https://gitlab.torproject.org/tpo/core/tor/-/issues/17817Add ipv6 authority and fallback flag to GETINFO config/defaults2020-06-27T14:00:01ZteorAdd ipv6 authority and fallback flag to GETINFO config/defaultslegacy/trac#17327 adds an ipv6=address:orport flag to authorities and fallback directories.
This should be included in GETINFO config/defaults.
Please see legacy/trac#16774 for work on including fallback directories in config/defaults.legacy/trac#17327 adds an ipv6=address:orport flag to authorities and fallback directories.
This should be included in GETINFO config/defaults.
Please see legacy/trac#16774 for work on including fallback directories in config/defaults.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17819pthread_condattr_setclock() used without checking its existence2020-06-27T14:00:00ZTracpthread_condattr_setclock() used without checking its existenceIn 0.2.7.5 (compare to 0.2.6.x) a call to pthread_condattr_setclock() was added without checking for its existence. This breaks compilation on NetBSD-6.x.
A configure check for that function should be added.
**Trac**:
**Username**: wizIn 0.2.7.5 (compare to 0.2.6.x) a call to pthread_condattr_setclock() was added without checking for its existence. This breaks compilation on NetBSD-6.x.
A configure check for that function should be added.
**Trac**:
**Username**: wizTor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17827Different return type of backtrace function on FreeBSD2020-06-27T14:00:00ZcypherpunksDifferent return type of backtrace function on FreeBSDJenkins is failing compilation on FreeBSD because its backtrace function is returning `size_t` instead of `int`. This leads to the compilation errors such as
```
../tor/src/common/backtrace.c:98:11: error: implicit conversion loses integ...Jenkins is failing compilation on FreeBSD because its backtrace function is returning `size_t` instead of `int`. This leads to the compilation errors such as
```
../tor/src/common/backtrace.c:98:11: error: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Werror,-Wshorten-64-to-32]
depth = backtrace(cb_buf, MAX_DEPTH);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../tor/src/common/backtrace.c:130:11: error: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Werror,-Wshorten-64-to-32]
depth = backtrace(cb_buf, MAX_DEPTH);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../tor/src/common/backtrace.c:177:17: error: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Werror,-Wshorten-64-to-32]
int depth = backtrace(cb_buf, MAX_DEPTH);
~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17837Move SOCKSPort open proxy warning to a more sensible location2021-07-22T16:25:32ZteorMove SOCKSPort open proxy warning to a more sensible locationThe SOCKSPort open proxy warning in the manual page is just below PreferIPv6.
It should probably be just under the first SOCKSPort paragraph. (Or, perhaps, right at the end of the flags.)
Here is what it says:
```
NOTE: Although this o...The SOCKSPort open proxy warning in the manual page is just below PreferIPv6.
It should probably be just under the first SOCKSPort paragraph. (Or, perhaps, right at the end of the flags.)
Here is what it says:
```
NOTE: Although this option allows you to specify an IP address
other than localhost, you should do so only with extreme
caution. The SOCKS protocol is unencrypted and (as we use it)
unauthenticated, so exposing it in this way could leak your
information to anybody watching your network, and allow anybody
to use your computer as an open proxy.
```Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17843Confusing double-quotes in config parse failure message2020-06-27T13:59:59ZRoger DingledineConfusing double-quotes in config parse failure messagePut
```
orport 1755800511a:443
```
in your torrc and then try to start Tor. You (rightly) get an error:
```
Dec 13 19:19:48.438 [warn] Couldn't parse address '"1755800511a:443"' for ORPort
```
But what is with the '"%s"' there? Shouldn'...Put
```
orport 1755800511a:443
```
in your torrc and then try to start Tor. You (rightly) get an error:
```
Dec 13 19:19:48.438 [warn] Couldn't parse address '"1755800511a:443"' for ORPort
```
But what is with the '"%s"' there? Shouldn't it just be quoted once, not twice in some weird nested way?
Encountered while trying to help a user debug his torrc, and the extra layer of "" made me think he was adding it explicitly somehow.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17847Unify router_pick_directory_server_impl and router_pick_trusteddirserver_impl2021-09-16T14:34:35ZteorUnify router_pick_directory_server_impl and router_pick_trusteddirserver_implrouter_pick_directory_server_impl and router_pick_trusteddirserver_impl are very similar.
I wonder if we could refactor them into a single function?
(Even if we have to use a macro to do it.)router_pick_directory_server_impl and router_pick_trusteddirserver_impl are very similar.
I wonder if we could refactor them into a single function?
(Even if we have to use a macro to do it.)https://gitlab.torproject.org/tpo/core/tor/-/issues/17849Warn if single-stack IPv4/IPv6 clients have very restricted guard choices2020-06-27T13:59:58ZteorWarn if single-stack IPv4/IPv6 clients have very restricted guard choicesYawning: The futueproof thing would be to warn if the selected protocol limits the number of guards to < N% probably?
Using what a dual stack host can reach as the baseline.Yawning: The futueproof thing would be to warn if the selected protocol limits the number of guards to < N% probably?
Using what a dual stack host can reach as the baseline.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17867Remove addresses and ports from dir_server_t and just use the ones in fake_st...2021-09-16T14:34:35ZteorRemove addresses and ports from dir_server_t and just use the ones in fake_statusWe put copies of an AuthDir / FallbackDir's addresses and ports in dir_server_t, and dir_server_t.fake_status. This is just asking for mistakes initialising them.
We could refactor the code so that we always use the addresses and ports ...We put copies of an AuthDir / FallbackDir's addresses and ports in dir_server_t, and dir_server_t.fake_status. This is just asking for mistakes initialising them.
We could refactor the code so that we always use the addresses and ports in fake_status.
This is not particularly urgent, because dir_server_t is read-only.https://gitlab.torproject.org/tpo/core/tor/-/issues/17882Remove needless *_support_ntor()2021-09-16T14:34:35ZNick MathewsonRemove needless *_support_ntor()While reviewing legacy/trac#7144, I noticed that circuit_cpath_supports_ntor() is pointless: We no longer allow TAP-only relays on the network, IIUC.
Assuming that I've got that right, we can rip out some code.While reviewing legacy/trac#7144, I noticed that circuit_cpath_supports_ntor() is pointless: We no longer allow TAP-only relays on the network, IIUC.
Assuming that I've got that right, we can rip out some code.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17901Tor would bind ControlPort to public ip address if it has no localhost interface2021-08-23T15:17:35Zs7rTor would bind ControlPort to public ip address if it has no localhost interfaceFreeBSD jails or some OpenVZ virtual machines do not have a `lo` interace (no 127.0.0.1 or localhost address), they only have an interface with either a public IP address either a NAT address routed upstream on the host.
In this case, i...FreeBSD jails or some OpenVZ virtual machines do not have a `lo` interace (no 127.0.0.1 or localhost address), they only have an interface with either a public IP address either a NAT address routed upstream on the host.
In this case, if ControlPort 9051 is set, it will open the control port on the public IP address without even a warning which is not funny. This applies also to SocksPort, but that's less scary than ControlPort.