Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:22:43Zhttps://gitlab.torproject.org/legacy/trac/-/issues/25415moria1 seg faults on testing relay reachability2020-06-13T15:22:43ZRoger Dingledinemoria1 seg faults on testing relay reachability```
[...]
Mar 03 15:09:16.138 [notice] This version of Tor (0.3.3.3-alpha-dev) is newer than any recommended version, according to the directory authorities. Recommended versions are: 0.2.5.16,0.2.5.17,0.2.9.14,0.2.9.15,0.3.1.9,0.3.1.10,...```
[...]
Mar 03 15:09:16.138 [notice] This version of Tor (0.3.3.3-alpha-dev) is newer than any recommended version, according to the directory authorities. Recommended versions are: 0.2.5.16,0.2.5.17,0.2.9.14,0.2.9.15,0.3.1.9,0.3.1.10,0.3.2.8-rc,0.3.2.9,0.3.2.10,0.3.3.1-alpha,0.3.3.2-alpha,0.3.3.3-alpha
============================================================ T= 1520107762
Tor 0.3.3.3-alpha-dev (git-6d44cf66c7cca6e0) died: Caught signal 11
../git/src/or/tor(+0x18d2aa)[0x7f7b748152aa]
../git/src/or/tor(tor_memeq+0x27)[0x7f7b748355e7]
../git/src/or/tor(tor_memeq+0x27)[0x7f7b748355e7]
../git/src/or/tor(router_ed25519_id_is_me+0x2a)[0x7f7b7472472a]
../git/src/or/tor(connection_or_connect+0x1a8)[0x7f7b747a1ad8]
../git/src/or/tor(channel_tls_connect+0xaa)[0x7f7b74758aaa]
../git/src/or/tor(dirserv_single_reachability_test+0xa8)[0x7f7b747c4108]
../git/src/or/tor(routerlist_descriptors_added+0x90)[0x7f7b7472b0a0]
../git/src/or/tor(router_load_routers_from_string+0x438)[0x7f7b747336a8]
../git/src/or/tor(+0xab81c)[0x7f7b7473381c]
../git/src/or/tor(router_reload_router_list+0x26)[0x7f7b74733926]
../git/src/or/tor(do_main_loop+0x2fb)[0x7f7b746db17b]
../git/src/or/tor(tor_run_main+0x29b)[0x7f7b746db88b]
../git/src/or/tor(tor_main+0x43)[0x7f7b746d61a3]
../git/src/or/tor(main+0x19)[0x7f7b746d6039]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f7b731f8d1d]
../git/src/or/tor(+0x4df49)[0x7f7b746d5f49]
Aborted
```
```
#0 0x00007ffff7ca55e7 in tor_memeq (a=<value optimized out>,
b=<value optimized out>, sz=<value optimized out>)
at src/common/di_ops.c:110
#1 0x00007ffff7b9472a in router_ed25519_id_is_me (id=<value optimized out>)
at src/or/routerkeys.c:1248
#2 0x00007ffff7c11ad8 in connection_or_connect (_addr=0x7fffffffe180,
port=443, id_digest=0x7fffeb96c8ac "\fÚ0ÍÛRku>K§\t8p;ïl´¸áv\237\232Z",
ed_id=0x20, chan=0x7ffffecb8230) at src/or/connection_or.c:1210
#3 0x00007ffff7bc8aaa in channel_tls_connect (addr=0x7fffffffe180, port=443,
id_digest=0x7fffeb96c8ac "\fÚ0ÍÛRku>K§\t8p;ïl´¸áv\237\232Z", ed_id=0x20)
at src/or/channeltls.c:206
#4 0x00007ffff7c34108 in dirserv_single_reachability_test (
now=<value optimized out>, router=0x7fffeb96c880) at src/or/dirserv.c:3405
#5 0x00007ffff7b9b0a0 in routerlist_descriptors_added (sl=0x7ffffb9b2900,
from_cache=1) at src/or/routerlist.c:4280
#6 0x00007ffff7ba36a8 in router_load_routers_from_string (
s=0x7fffee9720f8 "", eos=<value optimized out>,
saved_location=<value optimized out>, requested_fingerprints=0x0,
descriptor_digests=0, prepend_annotations=<value optimized out>)
at src/or/routerlist.c:4415
#7 0x00007ffff7ba381c in router_reload_router_list_impl (store=0x7ffff81306c0)
at src/or/routerlist.c:1565
#8 0x00007ffff7ba3926 in router_reload_router_list ()
at src/or/routerlist.c:1607
#9 0x00007ffff7b4b17b in do_main_loop () at src/or/main.c:2671
#10 0x00007ffff7b4b88b in tor_run_main (tor_cfg=<value optimized out>)
at src/or/main.c:4064
#11 0x00007ffff7b461a3 in tor_main (argc=3, argv=0x7fffffffe638)
at src/or/tor_api.c:84
#12 0x00007ffff7b46039 in main (argc=<value optimized out>,
argv=<value optimized out>) at src/or/tor_main.c:32
```
```
#0 0x00007ffff7ca55e7 in tor_memeq (a=<value optimized out>,
b=<value optimized out>, sz=<value optimized out>)
at src/common/di_ops.c:110
110 const uint8_t byte_diff = *ba++ ^ *bb++;
(gdb) up
#1 0x00007ffff7b9472a in router_ed25519_id_is_me (id=<value optimized out>)
at src/or/routerkeys.c:1248
1248 ed25519_pubkey_eq(id, &master_identity_key->pubkey);
(gdb) up
#2 0x00007ffff7c11ad8 in connection_or_connect (_addr=0x7fffffffe180,
port=443, id_digest=0x7fffeb96c8ac "\fÚ0ÍÛRku>K§\t8p;ïl´¸áv\237\232Z",
ed_id=0x20, chan=0x7ffffecb8230) at src/or/connection_or.c:1210
1210 if (server_mode(options) && router_ed25519_id_is_me(ed_id)) {
```
```
(gdb) print ed_id
$4 = (const ed25519_public_key_t *) 0x20
```Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/25400CIRC_BW event miscounts, should count all circ data2020-06-13T15:22:39ZMike PerryCIRC_BW event miscounts, should count all circ dataThe CIRC_BW event as implemented seems to be totaling only explicit application data on the circuit. To have an accurate representation of circuit usage, it should total all bytes sent on the circuit, including padding, dropped cells, an...The CIRC_BW event as implemented seems to be totaling only explicit application data on the circuit. To have an accurate representation of circuit usage, it should total all bytes sent on the circuit, including padding, dropped cells, and partially full cells.
Furthermore, it currently counts bytes differently depending on if you have the STREAM event enabled (see control_event_stream_bandwidth()). This is definitely a bug.Tor: 0.3.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/25399mmap length doesn't need to be page-aligned2020-06-13T15:22:38ZAlex Xummap length doesn't need to be page-alignedPOSIX says that mmap length doesn't need to be page-aligned. addr and off may have page alignment requirements, but length must be handled automatically. getpagesize is deprecated too.POSIX says that mmap length doesn't need to be page-aligned. addr and off may have page alignment requirements, but length must be handled automatically. getpagesize is deprecated too.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25398tests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set2020-06-13T15:22:38ZAlex Xutests fail if COMPAT_HAS_MMAN_AND_PAGESIZE is not set`tor_mmap_file` doesn't check for empty files if `COMPAT_HAS_MMAN_AND_PAGESIZE` is not set, causes `test_util_mmap` to fail`tor_mmap_file` doesn't check for empty files if `COMPAT_HAS_MMAN_AND_PAGESIZE` is not set, causes `test_util_mmap` to failTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25388document how to allow partially failing builds in Travis CI2020-06-13T15:22:37ZTaylor Yudocument how to allow partially failing builds in Travis CISometimes configurations that fewer developers regularly build with get merged with changes that break our Travis CI builds.
We should make it easier to temporarily allow those builds to fail while people work on getting them fixed, bec...Sometimes configurations that fewer developers regularly build with get merged with changes that break our Travis CI builds.
We should make it easier to temporarily allow those builds to fail while people work on getting them fixed, because sometimes it takes a while. This can include adding commented-out `allow_failure` clauses.Tor: 0.3.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/25386Link Rust Tests to C Dependencies in Tor (allow integration testing from Rust...2020-06-13T15:26:10ZAlex XuLink Rust Tests to C Dependencies in Tor (allow integration testing from Rust to C)currently, it is not possible to call C Tor, directly or indirectly, from rust tests. one of the following must be done:
1. provide rust stubs for all C functions that may be needed for tests (impractical)
2. test rust functions from C...currently, it is not possible to call C Tor, directly or indirectly, from rust tests. one of the following must be done:
1. provide rust stubs for all C functions that may be needed for tests (impractical)
2. test rust functions from C (so we will have C tests calling Rust functions calling C functions)
3. link C functions into rust doctests (preferred)
4. never call C-using rust functions in tests (leads to poor test coverage, very bad)
my branch https://cgit.alxu.ca/tor.git/commit/?h=fix-rust-tests implements option 3 poorly. this is a bad solution firstly because it is very ugly, and secondly because it does not properly pass the system linking arguments, e.g. -L/opt/ssl. thirdly, it may hide problems in or cause to be compiled incorrectly dependency crates.
this ticket blocks a number of rust improvements, since of course we would like to actually test the improvements, and doctests are the best way to do it in rust.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25381Add crypto_rand_double_sign() in C and Rust2020-06-13T15:22:33ZteorAdd crypto_rand_double_sign() in C and RustWe need a function that returns 1.0 or -1.0 with equal probability, so we can avoid weird tricks that waste floating point precision.
Since we want to use this in the laplace and guassian distributions, it needs to be implemented in bot...We need a function that returns 1.0 or -1.0 with equal probability, so we can avoid weird tricks that waste floating point precision.
Since we want to use this in the laplace and guassian distributions, it needs to be implemented in both C and Rust.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25372relay: Allocation for compression goes very high2020-06-13T15:22:27ZDavid Gouletdgoulet@torproject.orgrelay: Allocation for compression goes very highMy relay just OOMed some circuits with filled up queue (#25226) but then a useful log was printed showing that the compress total allocation is huge.
```
Feb 27 20:02:55.718 [notice] We're low on memory (cell queues total alloc: 2322798...My relay just OOMed some circuits with filled up queue (#25226) but then a useful log was printed showing that the compress total allocation is huge.
```
Feb 27 20:02:55.718 [notice] We're low on memory (cell queues total alloc: 232279872 buffer total alloc: 1937408, tor compress total alloc: 878586075 rendezvous cache total alloc: 4684497). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
```
That `878586075 = ~838MB`. My relay is hovering around 1.4GB of RAM right now which means ~60% of the RAM used is in the compression subsystem.
I'm not sure where it all comes, the relay is serving directory data but I have my doubt that *compressed*, it comes down to 800+ MB...
Datapoint:
```
$ du -sh diff-cache/
131M diff-cache/
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25368Update the Tor Rust coding standards for new types2020-06-13T15:24:12ZteorUpdate the Tor Rust coding standards for new typesI added some new types to the rust coding standards.
But I think I will need isis' help to explain Stringlist.I added some new types to the rust coding standards.
But I think I will need isis' help to explain Stringlist.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25355Add option to set the facility of the syslog log backend dynamically2020-06-13T15:22:24ZAlexander Færøyahf@torproject.orgAdd option to set the facility of the syslog log backend dynamicallyCurrently it's only possible to change our default syslog facility value if you compile Tor yourself and pass an option to the configure script. It should be possible to set this value, globally for all syslog loggers, in torrc.Currently it's only possible to change our default syslog facility value if you compile Tor yourself and pass an option to the configure script. It should be possible to set this value, globally for all syslog loggers, in torrc.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25341Remove now-unnecessary Rust linking workaround2020-06-13T15:22:20ZIsis LovecruftRemove now-unnecessary Rust linking workaroundWe've got the following stanza in our `configure.ac`:
```
dnl This is a workaround for #46797
dnl (a.k.a https://github.com/rust-lang/rust/issues/46797 ). O...We've got the following stanza in our `configure.ac`:
```
dnl This is a workaround for #46797
dnl (a.k.a https://github.com/rust-lang/rust/issues/46797 ). Once the
dnl upstream bug is fixed, we can remove this workaround.
case "$host_os" in
darwin*)
TOR_RUST_EXTRA_LIBS="-lresolv"
;;
esac
```
It looks like https://github.com/rust-lang/rust/issues/46797 has been resolved as of 22 January 2018, so we can probably remove this workaround now! (Someone who is on MacOS should probably test this, I don't have access to any Macs right now.)Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25306tor_assertion_failed_(): Bug: ../src/or/hs_service.c:1985: rotate_all_descrip...2020-06-13T15:22:13Zcypherpunkstor_assertion_failed_(): Bug: ../src/or/hs_service.c:1985: rotate_all_descriptors: Assertion service->desc_current failed; aborting.I got this error shortly after my computer clock jumped forward a couple of hours. Sadly the log is all I have.I got this error shortly after my computer clock jumped forward a couple of hours. Sadly the log is all I have.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25268cmux: Remove round robin code and make EWMA mandatory2020-06-13T15:22:05ZDavid Gouletdgoulet@torproject.orgcmux: Remove round robin code and make EWMA mandatorySince 0.2.4.x stable, Tor has been using EWMA circuit policy which is enabled by the consensus param: `CircuitPriorityHalflifeMsec=30000`
The `circuitmux.c` code still does quite a bit to maintain the round robin circuit policy that was...Since 0.2.4.x stable, Tor has been using EWMA circuit policy which is enabled by the consensus param: `CircuitPriorityHalflifeMsec=30000`
The `circuitmux.c` code still does quite a bit to maintain the round robin circuit policy that was used prior to EWMA. It hasn't been used since 024 (except in Chutney, see #25265).
A lot of that code is called for every cell tor receives so it is part of our fast path. Removing this round robin code would help in performance and remove complexity from the code.
However, that round robin functionality is used as a fallback if the EWMA policy was either not set or couldn't pick an active circuit (I'm not sure that is possible if we have active circuits).
Thus, the side effect of removing this code is that we'll now enforce a cmux to have a policy set and make the `pick_active_circuit()` callback mandatory. That is OK because we've been enforcing that since 024.
It would also probably mean that we need to put in a default value in tor code for `CircuitPriorityHalflifeMsec` so that if the consensus doesn't specify it, we fallback to a usable value instead of being able to disable EWMA.
This piece of work will help out with improving performance of the cmux subsystem with #25152 and make sure we stick to only the required code for this fast pathTor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25226Circuit cell queue can fill up memory2020-06-13T15:24:29ZDavid Gouletdgoulet@torproject.orgCircuit cell queue can fill up memoryA relay operator just reported this on 0.3.3.2-alpha:
https://lists.torproject.org/pipermail/tor-relays/2018-February/014496.html
In a nutshell, the OOM fired up with these logs:
```
Feb 12 18:54:55 tornode2 Tor[6362]: We're low on me...A relay operator just reported this on 0.3.3.2-alpha:
https://lists.torproject.org/pipermail/tor-relays/2018-February/014496.html
In a nutshell, the OOM fired up with these logs:
```
Feb 12 18:54:55 tornode2 Tor[6362]: We're low on memory (cell queues total alloc: 1602579792 buffer total alloc: 1388544, tor compress total alloc: 1586784 rendezvous cache total alloc: 489909). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
Feb 12 18:54:56 tornode2 Tor[6362]: Removed 1599323088 bytes by killing 1 circuits; 39546 circuits remain alive. Also killed 0 non-linked directory connections.
```
Notice the ~1GB of cells for one single circuit? Somehow, there is an issue in tor that makes it possible to fill up the circuit cell queue while the scheduler is just not emptying that queue.
This really looks like the Sniper Attack: http://www.robgjansen.com/publications/sniper-ndss2014.pdfTor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25188Spec bug in formal definition of Document in dir-spec.txt2020-06-13T15:21:48ZTracSpec bug in formal definition of Document in dir-spec.txtI was attempting to write a parser that reads vote/consensus documents using the the formal definition [here](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n210). However, I noticed an ambiguity.
Using only the formal defi...I was attempting to write a parser that reads vote/consensus documents using the the formal definition [here](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n210). However, I noticed an ambiguity.
Using only the formal definition, the following:
```
directory-signature 13241234321 12343234
-----BEGIN SIGNATURE-----
00thisisvalidbase64data12345
-----END SIGNATURE-----
```
Could be potentially parsed as
```
Document(
Item(
KeywordLine(
Keyword(KeywordChar+("directory-signature")),
WS,
ArgumentChar+("13241234321 12343234"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("-----BEGIN")),
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("00thisisvalidbase64data12345"))
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("-----END")),
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
)
```
When the correct parsing would be
```
Document(
Item(
KeywordLine(
Keyword(KeywordChar+("directory-signature")),
WS,
ArgumentChar+("13241234321 12343234"),
NL
),
Object(
BeginLine(
"-----BEGIN ",
Keyword(KeywordChar+("SIGNATURE")),
"-----",
NL
),
Base64-encoded-data("00thisisvalidbase64data12345"),
EndLine(
"-----END ",
Keyword(KeywordChar+("SIGNATURE")),
"-----",
NL
),
),
),
)
```
A potential change to the spec (assuming that keywords will never start with "-") that would prevent would be to replace
```
Keyword = KeywordChar+
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
```
with
```
Keyword = KeywordStartChar KeywordChar*
KeywordStartChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9'
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
```
**Trac**:
**Username**: witchof0x20Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25055string_is_valid_hostname() returns true for IPv4 addresses2020-06-13T15:21:16Zteorstring_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-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25036Tor 0.3.2 rejects connections to raw ipv6 addresses2020-06-13T15:21:14ZpastlyTor 0.3.2 rejects connections to raw ipv6 addressesOS X 10.11.6, Tor Browser 7.5
I have to configure TB to use a socks5 proxy to reach the internet (I predict this is unrelated). I disabled safe logging.
Attempting to go to https://[2a00:1450:401b:800::200e]/ (google) produces the foll...OS X 10.11.6, Tor Browser 7.5
I have to configure TB to use a socks5 proxy to reach the internet (I predict this is unrelated). I disabled safe logging.
Attempting to go to https://[2a00:1450:401b:800::200e]/ (google) produces the following Tor logs.
```
1/26/18, 14:51:25.600 [NOTICE] Bootstrapped 85%: Finishing handshake with first hop
1/26/18, 14:51:48.700 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit
1/26/18, 14:51:50.000 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
1/26/18, 14:51:50.000 [NOTICE] Bootstrapped 100%: Done
1/26/18, 14:51:50.900 [NOTICE] New control connection opened from 127.0.0.1.
1/26/18, 14:51:51.000 [NOTICE] New control connection opened from 127.0.0.1.
1/26/18, 14:54:06.900 [WARN] Your application (using socks5 to port 443) gave Tor a malformed hostname: "2a00:1450:401b:800::200e". Rejecting the connection.
1/26/18, 14:54:06.900 [WARN] Your application (using socks5 to port 443) gave Tor a malformed hostname: "2a00:1450:401b:800::200e". Rejecting the connection.
1/26/18, 14:55:38.200 [WARN] Your application (using socks5 to port 443) gave Tor a malformed hostname: "2a00:1450:401b:800::200e". Rejecting the connection.
1/26/18, 14:55:38.200 [WARN] Your application (using socks5 to port 443) gave Tor a malformed hostname: "2a00:1450:401b:800::200e". Rejecting the connection.
```
https://ipv6.google.com works with every 6th circuit. I'm sure this is unrelated and has to do with exits half supporing ipv6 or something.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25024Add optional spell check to makefile to check for typos in tor source code.2020-06-13T15:21:12ZTracAdd optional spell check to makefile to check for typos in tor source code.We should add a spell check to tor makefile somewhat like [https://github.com/client9/misspell] This ticket is an extension to #23650 [https://trac.torproject.org/projects/tor/ticket/23650]
**Trac**:
**Username**: fristonioWe should add a spell check to tor makefile somewhat like [https://github.com/client9/misspell] This ticket is an extension to #23650 [https://trac.torproject.org/projects/tor/ticket/23650]
**Trac**:
**Username**: fristonioTor: 0.3.4.x-finalAlison MacrinaAlison Macrinahttps://gitlab.torproject.org/legacy/trac/-/issues/24989Count hsdir requests against maxcircuitspending2020-06-13T15:21:07ZMike PerryCount hsdir requests against maxcircuitspendingIn #13837, we split off hsdir purposes from general. In the process, it means that we stopped counting hsdir circuits towards the global pending rate limit in count_pending_general_client_circuits(). That function was already trying to a...In #13837, we split off hsdir purposes from general. In the process, it means that we stopped counting hsdir circuits towards the global pending rate limit in count_pending_general_client_circuits(). That function was already trying to avoid counting hs circuits, but since nothing else globally limits the number of pending hs circuits, we probably should keep rate limiting hsdirs there, too.Tor: 0.3.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/24854Extract the authority list from config.c2020-06-13T15:20:14ZteorExtract the authority list from config.cThere is a list of default_authorities in src/or/config.c.
We want it in a separate file at src/or/auth_dirs.inc.
This should be implemented like the default_fallbacks array, which includes the fallback list from src/or/fallback_dirs.in...There is a list of default_authorities in src/or/config.c.
We want it in a separate file at src/or/auth_dirs.inc.
This should be implemented like the default_fallbacks array, which includes the fallback list from src/or/fallback_dirs.inc.
We will need to implement two branches for backporting:
* a branch on maint-0.2.9 for 0.2.9 and later. It has IPv6 addresses.
* ~~a branch on maint-0.2.5 for 0.2.5. It has no IPv6 addresses.~~
(Then, after we have moved it into a separate file, we want to automatically generate the file, in a new format. See the rest of the children of #24818.)Tor: 0.3.4.x-final