Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2023-05-12T18:28:13Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20165When a relay advertises a new, unreachable address, OR reachability can succe...2023-05-12T18:28:13ZteorWhen a relay advertises a new, unreachable address, OR reachability can succeed via the old addressIf a relay has advertised a reachable address in the past, and continues listening on the old address, clients and relays will continue to contact Tor on that address for a few hours.
If the relay starts advertising a new, unreachable a...If a relay has advertised a reachable address in the past, and continues listening on the old address, clients and relays will continue to contact Tor on that address for a few hours.
If the relay starts advertising a new, unreachable address, ORPort reachability will appear to succeed for that new address, because Tor doesn't (and probably can't) check the address clients are connecting to is the one it actually advertised.
And Tor doesn't do ongoing reachability checks, so it publishes its descriptor based on the mistaken reachability, and assumes everthing is OK from then on.
Fortunately, the mandatory DirPort check catches this in 0.2.8 and later.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40124Incorrect key ID type used in some ed25519 certificates2022-07-07T00:48:31ZNick MathewsonIncorrect key ID type used in some ed25519 certificatesIn `cert-spec.txt` we specify several possible values for the CERT_KEY_TYPE field, in section A.4. But we don't actually use those: everywhere that we call `tor_cert_sign_impl()` , signed_key type is set to `SIGNED_KEY_TYPE_ED25519`.
...In `cert-spec.txt` we specify several possible values for the CERT_KEY_TYPE field, in section A.4. But we don't actually use those: everywhere that we call `tor_cert_sign_impl()` , signed_key type is set to `SIGNED_KEY_TYPE_ED25519`.
We should adjust the spec to clarify that current tor implementations behave, and (assuming it won't introduce compatibility issue) adjust Tor relay behavior to conform to the spec. We should probably leave onion service behavior alone.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40073Bug: Tor 0.4.4.3-alpha: Assertion new_conn failed in retry_all_listeners at s...2022-07-07T00:48:30ZtoralfBug: Tor 0.4.4.3-alpha: Assertion new_conn failed in retry_all_listeners at src/core/mainloop/connection.c:3047I changed the torrc from
```
DirPort 80
ORPort 443
```
to
```
DirPort 5.9.158.75:80
ORPort 5.9.158.75:443
```
and runa "rc-service tor reload" hera at a hardened stable Gentoo Linux with sandboxing and got a
```
Jul 28 20:30:52.000 [n...I changed the torrc from
```
DirPort 80
ORPort 443
```
to
```
DirPort 5.9.158.75:80
ORPort 5.9.158.75:443
```
and runa "rc-service tor reload" hera at a hardened stable Gentoo Linux with sandboxing and got a
```
Jul 28 20:30:52.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jul 28 20:30:52.000 [notice] Read configuration file "/etc/tor/torrc".
Jul 28 20:30:52.000 [notice] Processing configuration path "/etc/tor/torrc.d/" at recursion level 1.
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//00_common".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//20_exit_flag".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//40_reject".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//80_accept".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//90_reject_all".
Jul 28 20:30:52.000 [notice] Opening Directory listener on 5.9.158.75:80
Jul 28 20:30:52.000 [warn] Could not bind to 5.9.158.75:80: Permission denied
Jul 28 20:30:52.000 [err] tor_assertion_failed_(): Bug: src/core/mainloop/connection.c:3047: retry_all_listeners: Assertion new_conn failed; aborting. (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: Tor 0.4.4.3-alpha: Assertion new_conn failed in retry_all_listeners at src/core/mainloop/connection.c:3047: . Stack trace: (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(log_backtrace_impl+0x59) [0x557166a32c19] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x150) [0x557166a2de10] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(retry_all_listeners+0x671) [0x55716689fac1] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(set_options+0xa48) [0x5571669ab908] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(+0x1776a0) [0x5571669ac6a0] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(options_init_from_string+0x119) [0x5571669ac8f9] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(options_init_from_torrc+0x372) [0x5571669acf12] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(+0x5d444) [0x557166892444] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/lib64/libevent-2.1.so.7(+0x21c86) [0x7f7a42484c86] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/lib64/libevent-2.1.so.7(event_base_loop+0x57f) [0x7f7a4248596f] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(do_main_loop+0xdd) [0x5571668a728d] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(tor_run_main+0x855) [0x557166893fa5] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(tor_main+0x46) [0x557166892176] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(main+0x19) [0x557166891d49] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7f7a41d26e2b] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(_start+0x2a) [0x557166891d9a] (on Tor 0.4.4.3-alpha )
```
Tor should IMO reject the config change in such a case, or?Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40034resolved_addr_set_suggested() cannot succeed2022-07-07T00:48:30ZNick Mathewsonresolved_addr_set_suggested() cannot succeedThis code will always trigger the BUG:
```
if (BUG(tor_addr_family(addr) != AF_INET ||
tor_addr_family(addr) != AF_INET6)) {
return;
}
```
Maybe this should be `&&`, not `||`?
Possibly related to #40032, possibly not....This code will always trigger the BUG:
```
if (BUG(tor_addr_family(addr) != AF_INET ||
tor_addr_family(addr) != AF_INET6)) {
return;
}
```
Maybe this should be `&&`, not `||`?
Possibly related to #40032, possibly not.
Found via a compiler warning on travis.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34357Reject relays running 0.4.12022-02-03T16:25:08ZNick MathewsonReject relays running 0.4.1Now that 0.4.1 has reached end-of-life, it's time for directory authorities to stop accepting relays running it.
See legacy/trac#32672 for the last time we did this.
Looking at the graphs, I don't see a significant change in the drop-o...Now that 0.4.1 has reached end-of-life, it's time for directory authorities to stop accepting relays running it.
See legacy/trac#32672 for the last time we did this.
Looking at the graphs, I don't see a significant change in the drop-off rate for deprecated versions in between when we announced that they were deprecated, and when we finally removed them. Maybe this time we should just send out an announcment, wait a month, then reject the relays?Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18106Rename fascist_firewall_* functions to reachable_address_*2021-09-16T14:34:11ZteorRename fascist_firewall_* functions to reachable_address_*In legacy/trac#17840 and legacy/trac#9067 / legacy/trac#9068, we unified ReachableAddresses and ClientUseIPv4/ClientUseIPv6/UseBridges. We'd previously unified FascistFirewall, FirewallPorts and ReachableAddresses.
This means that the f...In legacy/trac#17840 and legacy/trac#9067 / legacy/trac#9068, we unified ReachableAddresses and ClientUseIPv4/ClientUseIPv6/UseBridges. We'd previously unified FascistFirewall, FirewallPorts and ReachableAddresses.
This means that the functions called fascist_firewall_* should probably be renamed to be more descriptive.
I think reachable_address_* is one option, but let's follow typical naming standards and not repeat words in names:
* fascist_firewall_choose_address_dir_server ->
* reachable_address_choose_address_dir_server ->
* reachable_address_choose_dir_server
Let's also use this as an opportunity to disambiguate fascist_firewall_choose_address_impl & fascist_firewall_choose_address_base.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22881Unreachable relays launch multiple testing circuits per second2021-09-16T14:31:59ZteorUnreachable relays launch multiple testing circuits per secondWhen I start a relay behind a NAT with:
```
tor ORPort 12345 PublishServerDescriptor 0 Log "info stderr"
```
I see it launch multiple testing circuits every second.
This places a lot of load on the network: it should use exponential bac...When I start a relay behind a NAT with:
```
tor ORPort 12345 PublishServerDescriptor 0 Log "info stderr"
```
I see it launch multiple testing circuits every second.
This places a lot of load on the network: it should use exponential backoff instead.
We wanted to fix things like this as part of legacy/trac#4580 or legacy/trac#8625, but it seems we missed this case. Maybe we need to do exponential backoff at a lower level than directory requests?
Here are the log messages for one second:
```
Jul 11 19:07:20.000 [info] circuit_finish_handshake: Finished building circuit hop:
Jul 11 19:07:20.000 [info] internal circ (length 3, last hop Unnamed): $3E13E2EB87CCF5690564EE33E9F9F9F80B229FBB(open) $34D2E3C853C6C60A5CCD93E363CD524BA962D3D6(open) $4345CA43B1F4E1C08271F8FA907B4AE890591111(closed)
Jul 11 19:07:20.000 [info] circuit_send_next_onion_skin: Sending extend relay cell.
Jul 11 19:07:20.000 [info] consider_testing_reachability: Testing reachability of my ORPort: 124.171.199.202:12345.
Jul 11 19:07:20.000 [info] onion_pick_cpath_exit: Using requested exit node '$4345CA43B1F4E1C08271F8FA907B4AE890591111~Unnamed at 124.171.199.202'
Jul 11 19:07:20.000 [info] extend_info_from_node: Not including the ed25519 ID for $7202A9449EC084A305EB19A2A2A0E245FA8C111E~jonasBebe2 at 193.200.241.195, since it won't be able to authenticate it.
Jul 11 19:07:20.000 [info] extend_info_from_node: Not including the ed25519 ID for $CA618B8FB8FDF1C670BA7139B1E3EFCE25771551~bentleywashere3 at 198.199.90.205, since it won't be able to authenticate it.
Jul 11 19:07:20.000 [info] circuit_handle_first_hop: Next router is [scrubbed]: Not connected. Connecting.
Jul 11 19:07:20.000 [info] connection_or_set_identity_digest: Set identity digest for 0x7fcefb6f1cd0 ([scrubbed]): 7202A9449EC084A305EB19A2A2A0E245FA8C111E <unset>.
Jul 11 19:07:20.000 [info] connection_or_set_identity_digest: (Previously: 0000000000000000000000000000000000000000 <unset>)
Jul 11 19:07:20.000 [info] channel_tls_process_versions_cell: Negotiated version 4 with [scrubbed]:443; Sending cells: CERTS
Jul 11 19:07:20.000 [info] connection_or_client_learned_peer_id: learned peer id for 0x7fcefaf87090 ([scrubbed]): 650ABAB06345EEC29BB0B5322C27DC6E5E888019, <null>
Jul 11 19:07:20.000 [info] channel_tls_process_certs_cell: Got some good certificates from [scrubbed]:443: Authenticated it with RSA
Jul 11 19:07:20.000 [info] channel_tls_process_auth_challenge_cell: Got an AUTH_CHALLENGE cell from [scrubbed]:443: Sending authentication type 1
Jul 11 19:07:20.000 [info] circuit_send_next_onion_skin: First hop: finished sending CREATE cell to '$650ABAB06345EEC29BB0B5322C27DC6E5E888019~supc0re at 217.160.15.198'
Jul 11 19:07:20.000 [info] channel_tls_process_netinfo_cell: Got good NETINFO cell from [scrubbed]:443; OR connection is now open, using protocol version 4. Its ID digest is 650ABAB06345EEC29BB0B5322C27DC6E5E888019. Our address is apparently 124.171.199.202.
Jul 11 19:07:20.000 [info] circuit_expire_building: Abandoning circ 198 37.187.3.106:443:3622949943 (state 0,0:doing handshakes, purpose 18, len 3)
Jul 11 19:07:20.000 [info] internal circ (length 3, last hop Unnamed): $597422ADDADAF5FB2727369B7EFC7AA76B89D613(open) $E7578F3484C8ABD5FB3130E31F30C167206BCA7E(open) $4345CA43B1F4E1C08271F8FA907B4AE890591111(waiting for keys)
Jul 11 19:07:20.000 [info] circuit_testing_failed: Our testing circuit (to see if your ORPort is reachable) has failed. I'll try again later.
Jul 11 19:07:20.000 [info] circuit_finish_handshake: Finished building circuit hop:
Jul 11 19:07:20.000 [info] internal circ (length 3, last hop Unnamed): $650ABAB06345EEC29BB0B5322C27DC6E5E888019(open) $45D6A70CAEC4A2C2FCE46A127E461FF852A41280(closed) $4345CA43B1F4E1C08271F8FA907B4AE890591111(closed)
Jul 11 19:07:20.000 [info] circuit_send_next_onion_skin: Sending extend relay cell.
```Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30797Stop shipping an abandoned systemd script?2021-09-16T14:23:38ZRoger DingledineStop shipping an abandoned systemd script?legacy/trac#19759, legacy/trac#19761, legacy/trac#19762 are bugs filed on the systemd script that we ship in "contrib/dist/tor.service.in".
The bugs haven't been looked at in years, and it looks like nobody on our side is paying attenti...legacy/trac#19759, legacy/trac#19761, legacy/trac#19762 are bugs filed on the systemd script that we ship in "contrib/dist/tor.service.in".
The bugs haven't been looked at in years, and it looks like nobody on our side is paying attention to this systemd script. That sounds to me like we would consider people foolish if they tried to use it.
Should we confirm that somebody, somewhere else on the internet, has a better systemd script than we do, and then remove ours?Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31829Drop support for Python 22021-09-16T14:22:37ZNick MathewsonDrop support for Python 2Tor doesn't need Python to build, but several of our tests require Python to run.
Python 2 will reach end of life on Jan 1 2020 (see https://pythonclock.org/). Let's help it out by:
* Making our configure script only detect python 3...Tor doesn't need Python to build, but several of our tests require Python to run.
Python 2 will reach end of life on Jan 1 2020 (see https://pythonclock.org/). Let's help it out by:
* Making our configure script only detect python 3 as a usable python.
* Removing gross python2 workarounds from our scripts.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/32776Remove 0.2.9 from the jenkins builders2021-09-16T14:22:16ZteorRemove 0.2.9 from the jenkins buildersI don't know how to change jenkins configs, but I think we need to make a patch, then put it in the jenkins component?I don't know how to change jenkins configs, but I think we need to make a patch, then put it in the jenkins component?Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40136Revise doc/state-contents.txt to be accurate2021-09-16T14:21:52ZNick MathewsonRevise doc/state-contents.txt to be accurateThe doc/state-contents.txt file is out of date, and missing a bunch of documentation.
We should have accurate documentation for all of the state file's contents.
The following elements are undocumented:
* BWHistoryIPv6ReadEnds
* BWHi...The doc/state-contents.txt file is out of date, and missing a bunch of documentation.
We should have accurate documentation for all of the state file's contents.
The following elements are undocumented:
* BWHistoryIPv6ReadEnds
* BWHistoryIPv6ReadInterval
* BWHistoryIPv6ReadValues
* BWHistoryIPv6ReadMaxima
* BWHistoryIPv6WriteEnds
* BWHistoryIPv6WriteInterval
* BWHistoryIPv6WriteValues
* BWHistoryIPv6WriteMaxima
* Guard
* TotalBuildTimes
* CircuitBuildAbandonedCount
* "CircuitBuildTimeBin"
* "BuildtimeHistogram"
* "MinutesSinceUserActivity"
* "Dormant"
The follow elements are obsolete:
* "EntryGuard"
* "EntryGuardDownSince"
* "EntryGuardUnlistedSince"
* "EntryGuardAddedBy"
These are obsolete _and_ undocumented:
* "EntryGuardPathBias"
* "EntryGuardPathUseBias"
* HidServRevCounterTor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40102Make options_init_from_torrc smaller2021-09-16T14:21:52ZJigsaw52Make options_init_from_torrc smalleroptions_init_from_torrc is a very large function that implements some of the tor command line options inside it. These could be easily split into each own function.options_init_from_torrc is a very large function that implements some of the tor command line options inside it. These could be easily split into each own function.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40046Define and use `CONST_TO_FOO_CONN()`2021-09-16T14:21:52ZNick MathewsonDefine and use `CONST_TO_FOO_CONN()`We frequently do this:
```
const connection_t *conn = ...;
const or_connection_t *or_conn = TO_OR_CONN((connection_t*)conn);
```
Instead let's define a CONST_TO_OR_CONN() variant, like we have for circuits. We can do similar for th...We frequently do this:
```
const connection_t *conn = ...;
const or_connection_t *or_conn = TO_OR_CONN((connection_t*)conn);
```
Instead let's define a CONST_TO_OR_CONN() variant, like we have for circuits. We can do similar for the other connection types.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40042Give or_connection_t a "canonical_addr" field rather than "real_addr".2021-09-16T14:21:52ZNick MathewsonGive or_connection_t a "canonical_addr" field rather than "real_addr".We want to avoid messing with the `addr` field in or_connection_t objects. (See #33898 for more info.) Having this field is what forced us to add a `real_addr` field.
Instead, let's get a `canonical_addr` field to track the canonical a...We want to avoid messing with the `addr` field in or_connection_t objects. (See #33898 for more info.) Having this field is what forced us to add a `real_addr` field.
Instead, let's get a `canonical_addr` field to track the canonical address of a relay, and use that when appropriate.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40041Add and use "describe connection" and "describe peer" functions.2021-09-16T14:21:52ZNick MathewsonAdd and use "describe connection" and "describe peer" functions.As examined in #33898, the address-related fields on our `connection_t` objects are a big mess.
Part of our plan to simplify the use around them is to stop using them in log messages. Instead we should have functions for describing a co...As examined in #33898, the address-related fields on our `connection_t` objects are a big mess.
Part of our plan to simplify the use around them is to stop using them in log messages. Instead we should have functions for describing a connection, and describing its peer, and use those instead.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40040Document behavior of addr/address/real_addr fields2021-09-16T14:21:52ZNick MathewsonDocument behavior of addr/address/real_addr fieldsAs examined in #33898, the address-related fields on our `connection_t` objects are a big mess.
We came up with a plan there to make progress on the situation. The first step is to document how the fields are used and modified today, an...As examined in #33898, the address-related fields on our `connection_t` objects are a big mess.
We came up with a plan there to make progress on the situation. The first step is to document how the fields are used and modified today, and suggest alternatives to direct use and inspection of those fields.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7193Tor's sybil protection doesn't consider IPv62021-08-23T15:19:19ZGeorge KadianakisTor's sybil protection doesn't consider IPv6Some bugs:
`get_possible_sybil_list()` doesn't consider IPv6 addresses at all.
~~`clear_status_flags_on_sybil()` doesn't clear `ipv6_addr` (and maybe more flags).~~ Obsoleted by consensus method 24, because it requires the Running flag...Some bugs:
`get_possible_sybil_list()` doesn't consider IPv6 addresses at all.
~~`clear_status_flags_on_sybil()` doesn't clear `ipv6_addr` (and maybe more flags).~~ Obsoleted by consensus method 24, because it requires the Running flag for a router to be in the consensus.
Also, maybe we could add a `log_notice` or `log_info` to mention if and which relays were found to be part of a Sybil attack.
~~Finally (and this is a minor bug), in `get_possible_sybil_list()` we assume that `max_with_same_addr < max_with_same_addr_on_authority`, which is true in the current tor network, but maybe it shouldn't be an inherent property of the source code.~~ Obsoleted by legacy/trac#20960: max_with_same_addr_on_authority has been removed.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33239Prop 312: 3.2.3 Limit Directory Authority Addresses to Address and ORPort2021-08-23T15:12:44ZteorProp 312: 3.2.3 Limit Directory Authority Addresses to Address and ORPortFor security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Since local interface addresses are
implicit, and may depend on DHCP, directory authorities do not use this
address resolution ...For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Since local interface addresses are
implicit, and may depend on DHCP, directory authorities do not use this
address resolution method (or any of the other, lower-priority address
resolution methods).
See proposal 312, section 3.2.3, directory authority case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n388Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33237Prop 312: 3.2.2. Stop Directory Authorities Resolving *Port Hostnames2021-08-23T15:12:44ZteorProp 312: 3.2.2. Stop Directory Authorities Resolving *Port HostnamesFor security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort an...For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort and DirPort options.
As part of this fix, we may also ban DNS resolution on all configured Ports. (We should try to avoid banning DNS resolution entirely on authorities, because some test networks use Authority/Exits.)
See proposal 312, section 3.2.2, directory authority case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n340
Directory authorities must not attempt to resolve these
addresses using DNS. It is a config error to provide a hostname as a
directory authority's ORPort or DirPort.
If directory authorities don't have an IPv4 address literal in their
Address or ORPort, they should issue a configuration error, and refuse to
launch. If directory authorities don't have an IPv6 address literal in their
Address or ORPort, they should issue a notice-level log, and fall back to
only using IPv4.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/32661Document that we avoid changing src/ext2021-07-22T16:19:07ZteorDocument that we avoid changing src/extWe only change src/ext when necessary for integration with tor, or portability across platforms.
There was some confusion about this in legacy/trac#32626, so I'd like to update one or more of the following documents:
* src/mainpage.md
*...We only change src/ext when necessary for integration with tor, or portability across platforms.
There was some confusion about this in legacy/trac#32626, so I'd like to update one or more of the following documents:
* src/mainpage.md
* src/ext/README
* doc/HACKING/CodeStructure.md
We might also want to change our merge policy, but that's a longer process.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewson