Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-08-07T17:16:00Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27736Make sure that Tor doesn't build an IPv4 and an IPv6 connection to the same r...2020-08-07T17:16:00ZteorMake sure that Tor doesn't build an IPv4 and an IPv6 connection to the same relayWhen we implement legacy/trac#17835, Tor will choose between IPv4 and IPv6 at random.
I'm pretty sure that we prefer existing connections to the same relay, even if the chosen address doesn't match.
But I need to read the client code t...When we implement legacy/trac#17835, Tor will choose between IPv4 and IPv6 at random.
I'm pretty sure that we prefer existing connections to the same relay, even if the chosen address doesn't match.
But I need to read the client code to make sure this check is done on clients and relays. And I need to run the new code to make sure we're not doubling the number of connections that Tor clients make.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27648Stop setting the IPv6 preferred flag on nodes2020-07-28T23:00:38ZteorStop setting the IPv6 preferred flag on nodesInstead:
* for guards, decide on the address to use at random
* for bridges, decide on the address to use at random, but make it more likely that we will use the configured addressInstead:
* for guards, decide on the address to use at random
* for bridges, decide on the address to use at random, but make it more likely that we will use the configured addressTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27647When randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6 weight2020-06-27T13:52:13ZteorWhen randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6 weightWe can't make 50% of clients use IPv6 until most relays have IPv6. Otherwise, we would overload the IPv6 Guards. Right now, about 25% of Guard consensus weight has IPv6:
https://metrics.torproject.org/advbw-ipv6.html
When we are randoml...We can't make 50% of clients use IPv6 until most relays have IPv6. Otherwise, we would overload the IPv6 Guards. Right now, about 25% of Guard consensus weight has IPv6:
https://metrics.torproject.org/advbw-ipv6.html
When we are randomly choosing IPv4 or IPv6, we need to set the initial IPv6 probability based on the IPv6 Guard consensus weight. (Or the number of IPv6 bridges, if we're using bridges.)
With IPv4-only, IPv6-only, and DualStack Entry nodes, the formulas are:
```
IPv4-capable-weight = IPv4-only + DualStack
IPv6-capable-weight = IPv6-only + DualStack
Total-weight = IPv4-only + IPv6-only + DualStack
IPv4-capable-fraction = IPv4-capable-weight / Total-weight
IPv6-capable-fraction = IPv6-capable-weight / Total-weight
IPv4-probability = IPv4-capable-fraction / (IPv4-capable-fraction + IPv6-capable-fraction)
IPv6-probability = IPv6-capable-fraction / (IPv4-capable-fraction + IPv6-capable-fraction)
```
We should update these probabilities whenever we get a new consensus, new bridge lines, or new bridge descriptors.Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27491Prefer IPv4 or IPv6 based on the number of failures2020-06-27T13:52:17ZNeel Chauhanneel@neelc.orgPrefer IPv4 or IPv6 based on the number of failuresSuggested by teor at legacy/trac#17835:
> 3. If the machine instantly fails IPv4 or IPv6 connections, stop those connections for a while
> 4. When there are a lot more IPv4 than IPv6 failures, don't try IPv4 as much
> 5. When there are ...Suggested by teor at legacy/trac#17835:
> 3. If the machine instantly fails IPv4 or IPv6 connections, stop those connections for a while
> 4. When there are a lot more IPv4 than IPv6 failures, don't try IPv4 as much
> 5. When there are a lot more IPv6 than IPv4 failures, don't try IPv6 as much
> 6. After a while, forget old failuresTor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27490When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a...2020-06-27T13:52:17ZNeel Chauhanneel@neelc.orgWhen ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomSuggested by teor at legacy/trac#17835:
>1. Make ClientPreferIPv6ORPort into an autobool
>2. When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomSuggested by teor at legacy/trac#17835:
>1. Make ClientPreferIPv6ORPort into an autobool
>2. When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomTor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27284Check IPv6 exit policies on microdescs2020-06-27T13:52:28ZteorCheck IPv6 exit policies on microdescsIn node_exit_policy_rejects_all(), we check IPv4 and IPv6 policies on ri, but on md we only check IPv4:
```
else if (node->md)
return node->md->exit_policy == NULL ||
short_policy_is_reject_star(node->md->exit_policy);
```
O...In node_exit_policy_rejects_all(), we check IPv4 and IPv6 policies on ri, but on md we only check IPv4:
```
else if (node->md)
return node->md->exit_policy == NULL ||
short_policy_is_reject_star(node->md->exit_policy);
```
One way to fix this issue is to refactor the existing code to check a new policy_is_reject_star, and then populate policy_is_reject_star when the md is parsed. (Like we already do with the ri.)Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27251Add single-onion-v23-ipv6-md to make test-network-all2021-09-30T13:45:56ZteorAdd single-onion-v23-ipv6-md to make test-network-allWhen IPv6 single onion services work, we should add the single-onion-v23-ipv6-md to TEST_CHUTNEY_FLAVORS_IPV6in src/test/include.am.
We can also remove single-onion-ipv6-md, because it's redundant.When IPv6 single onion services work, we should add the single-onion-v23-ipv6-md to TEST_CHUTNEY_FLAVORS_IPV6in src/test/include.am.
We can also remove single-onion-ipv6-md, because it's redundant.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27204add info for IPv6-only hosts to torrc man page2021-07-22T16:20:36Ztraumschuleadd info for IPv6-only hosts to torrc man pageAdd a sentence to the ClientUseIPv6 section of the tor man page:
> For IPv6 only hosts, you need to also set **ClientUseIPv4** to 0 to disable IPv4.Add a sentence to the ClientUseIPv6 section of the tor man page:
> For IPv6 only hosts, you need to also set **ClientUseIPv4** to 0 to disable IPv4.Tor: 0.3.5.x-finaltraumschuletraumschulehttps://gitlab.torproject.org/tpo/core/tor/-/issues/27086Write unit tests for fascist_firewall_choose_address_ls() and hs_get_extend_i...2021-09-30T13:45:56ZteorWrite unit tests for fascist_firewall_choose_address_ls() and hs_get_extend_info_from_lspecs()The branch in legacy/trac#23588 doesn't have unit tests, so we should write some.The branch in legacy/trac#23588 doesn't have unit tests, so we should write some.Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/26992Add intro point IPv6 address to service descriptors2021-09-30T13:45:56ZteorAdd intro point IPv6 address to service descriptorsImplemented as a consequence of legacy/trac#23576, but I need a ticket number.Implemented as a consequence of legacy/trac#23576, but I need a ticket number.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26971Add rendezvous point unrecognised link specifiers to client introduce cells2022-06-16T18:01:57ZteorAdd rendezvous point unrecognised link specifiers to client introduce cellsLike legacy/trac#24181, we need to take unrecognised link specifiers from onion service descriptors, and put them in client introduce cells.
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1346Like legacy/trac#24181, we need to take unrecognised link specifiers from onion service descriptors, and put them in client introduce cells.
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1346https://gitlab.torproject.org/tpo/core/tor/-/issues/26664When an exit tells a client about an IPv6-only hostname, the client should ch...2022-06-17T14:15:14ZteorWhen an exit tells a client about an IPv6-only hostname, the client should choose another IPv6 exitWhen legacy/trac#21311 and legacy/trac#21310 are finished, we need to make clients choose an IPv6 exit when an exit tells them they are connecting to an IPv6-only site
We can't choose an exit for the specific IPv6 address, because that ...When legacy/trac#21311 and legacy/trac#21310 are finished, we need to make clients choose an IPv6 exit when an exit tells them they are connecting to an IPv6-only site
We can't choose an exit for the specific IPv6 address, because that leads to tagging attacks.https://gitlab.torproject.org/tpo/core/tor/-/issues/26436Check uses of CMP_SEMANTIC for IP addresses2021-09-16T14:30:20ZteorCheck uses of CMP_SEMANTIC for IP addressesFrom legacy/trac#24546 comment 1:
We should also audit all uses of tor_addr_compare(a1, a2, CMP_EXACT) to see if they should be CMP_SEMANTIC instead.
The current uses of CMP_SEMANTIC seem reasonable, but not essential: they code would s...From legacy/trac#24546 comment 1:
We should also audit all uses of tor_addr_compare(a1, a2, CMP_EXACT) to see if they should be CMP_SEMANTIC instead.
The current uses of CMP_SEMANTIC seem reasonable, but not essential: they code would still work if we rejected mapped addresses and did exact comparisons instead.https://gitlab.torproject.org/tpo/core/tor/-/issues/26303IPv6-Flagging of Relay not accurate2020-06-27T13:53:15ZTracIPv6-Flagging of Relay not accurateOur Node (D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA) is reachable via IPv6, but gets flagged with "unreachable IPv6" by the Consensus.
All IPv6-enabled Authorities can be pinged successfully via IPv6 from the Relay, and the advertised Po...Our Node (D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA) is reachable via IPv6, but gets flagged with "unreachable IPv6" by the Consensus.
All IPv6-enabled Authorities can be pinged successfully via IPv6 from the Relay, and the advertised Ports are open for connections via IPv6.
**Trac**:
**Username**: ruebezahlTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25784Misleading error message when asking for IPv6 in a network with no IPv6-capab...2020-07-28T19:09:59ZpastlyMisleading error message when asking for IPv6 in a network with no IPv6-capable exitsI created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
I didn't set `IPv6Exit 1` on any of the exits.
I had a client try to request `::1` over this Tor network on a hand crafted circuit (it makes sense to ask an e...I created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
I didn't set `IPv6Exit 1` on any of the exits.
I had a client try to request `::1` over this Tor network on a hand crafted circuit (it makes sense to ask an exit to connect to localhost when this is all local ... trust me). I got the following confusing error message on the client.
> [warn] I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's not going to work. Did you perhaps ask for an IPv6 address on an IPv4Only port, or vice versa?
I think it's important to point out (again) that I was hand crafting these circuits and was not considering IPv6 support. That said, I don't know what Tor would do if I let it make the circuit for me and it couldn't find an IPv6-supporting exit.
As you can see, I'm talking myself out of this being a bug and it just being me screwing things up for myself. I was encouraged to make a ticket though, so here we are.
If rewriting the error message is the solution, maybe after fixing the "fulfil" typo, we should add "It's also possible we couldn't find any exits supporting the IP version you want to use"
I'm picking 0.3.5.x-final just because I've been told you have to pick a milestone or else your tickets generally fall through the cracks. :)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25245Crash in assert_connection_ok when changing Exit options2020-06-27T13:54:09ZtoralfCrash in assert_connection_ok when changing Exit optionsGot this today:
```
Feb 13 22:02:49.000 [err] tor_assertion_failed_(): Bug: src/or/connection.c:5113: assert_connection_ok: Assertion (conn->type == CONN_TYPE_EXIT && conn->state == EXIT_CONN_STATE_RESOLVING) || connection_is_writing(con...Got this today:
```
Feb 13 22:02:49.000 [err] tor_assertion_failed_(): Bug: src/or/connection.c:5113: assert_connection_ok: Assertion (conn->type == CONN_TYPE_EXIT && conn->state == EXIT_CONN_STATE_RESOLVING) || connection_is_writing(conn) || conn->write_blocked_on_bw || (CONN_IS_EDGE(conn) && TO_EDGE_CONN(conn)->edge_blocked_on_circ) failed; aborting. (on Tor 0.3.3.2-alpha efc105716283bbdf)
```
Before I changed the config from
ExitRelay 1
IPv6Exit 1
to
#ExitRelay 1
#IPv6Exit 1
and a little bit later to
ExitRelay 0
IPv6Exit 0
and run a kill -HUP (after every config change)Tor: 0.3.5.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/252130.3.3.2-alpha - Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)...2020-06-27T13:54:10ZTrac0.3.3.2-alpha - Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)) failed.Running 2 tor relays, whilst restarting Tor going from 0.3.3.1-alpha-dev to 0.3.3.2-alpha one of the two nodes gave the following error for 3 other relays, being: Rea, fury and lowtideceviche
It's just running for 2 hours or so, the rem...Running 2 tor relays, whilst restarting Tor going from 0.3.3.1-alpha-dev to 0.3.3.2-alpha one of the two nodes gave the following error for 3 other relays, being: Rea, fury and lowtideceviche
It's just running for 2 hours or so, the remaining functionality seems OK.
Feb 11 20:01:04 tornode1 Tor[23044]: tor_bug_occurred_(): Bug: ../src/or/policies.c:1008: fascist_firewall_choose_address_node: Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)) failed. (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)) failed in fascist_firewall_choose_address_node at ../src/or/policies.c:1008. Stack trace: (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(log_backtrace+0x44) [0x55a3a4d5bde4] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x55a3a4d77479] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(fascist_firewall_choose_address_node+0x182) [0x55a3a4c47682] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(extend_info_from_node+0x12f) [0x55a3a4caaa7f] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(+0xed980) [0x55a3a4cc0980] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x261) [0x55a3a4cc0eb1] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(connection_ap_attach_pending+0x1a8) [0x55a3a4ce2808] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(do_main_loop+0x399) [0x55a3a4c278f9] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(tor_run_main+0x275) [0x55a3a4c28f25] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(tor_main+0x3a) [0x55a3a4c2236a] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(main+0x19) [0x55a3a4c220d9] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f6eb6b052b1] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(_start+0x2a) [0x55a3a4c2212a] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Could not choose valid address for Rea
Feb 11 20:01:04 tornode1 Tor[23044]: Could not make a one-hop connection to $8DCB8A8CD726EBCE5CCC90581EB7A695D6B09904. Discarding this circuit.
**Trac**:
**Username**: sjcjonkerTor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25211Tor fails to resolve ipv6.google.com2020-06-27T13:54:10Zrl1987Tor fails to resolve ipv6.google.commacOS 11.13.2, Tor Browser 7.5, Tor 1df701c082761775d311a966a222bca116afc3c2
Trying to access https://ipv6.google.com tends to fail with following messages in the log:
```
Feb 11 17:44:43.000 [info] connection_ap_process_end_not_open: ...macOS 11.13.2, Tor Browser 7.5, Tor 1df701c082761775d311a966a222bca116afc3c2
Trying to access https://ipv6.google.com tends to fail with following messages in the log:
```
Feb 11 17:44:43.000 [info] connection_ap_process_end_not_open: Address '[scrubbed]' refused due to 'resolve failed'. Considering retrying.
Feb 11 17:44:43.000 [info] client_dns_incr_failures: Address [scrubbed] now has 3 resolve failures.
Feb 11 17:44:43.000 [notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
```https://gitlab.torproject.org/tpo/core/tor/-/issues/25182systemd unit file starts Tor before IPv6 address is available2020-06-27T13:54:12ZSteven Murdochsystemd unit file starts Tor before IPv6 address is availableOn Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address a...On Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address assigned and hence Tor fails to start.
As a work-around I copied `/lib/systemd/system/tor*` to `/etc/systemd/system/` and added `RestartSec=10` to the `[Service]` section of `tor@default.service` and `tor@.service`. This slows down the restart such that by the second time tor starts, there is an IPv6 address available.
See log file below.
```
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.587 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.591 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1313]: Configuration was valid
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Scheduler type KIST has been enabled.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on [2001:630:212:2a8:a6bf:1ff:fe25:b961]:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Could not bind to 2001:630:212:2a8:a6bf:1ff:fe25:b961:9001: Cannot assign requested address
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [err] Reading config failed--see warnings above.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit tor@default.service has failed
-- Unit tor@default.service has failed.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Unit entered failed state.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Failed with result 'exit-code'.
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25055string_is_valid_hostname() returns true for IPv4 addresses2020-06-27T13:54:18Zteorstring_is_valid_hostname() returns true for IPv4 addressesIf it is meant to return true for all IP addresses, it should return true for IPv6 as well.
If it's meant to return true just for hostnames, it should reject IPv4 addresses.
a valid host name can never have the dotted-decimal form #...If it is meant to return true for all IP addresses, it should return true for IPv6 as well.
If it's meant to return true just for hostnames, it should reject IPv4 addresses.
a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic
https://tools.ietf.org/html/rfc1123#page-13
Then we should check every use of this function, to make sure it is being used the right way.Tor: 0.3.3.x-final