October 2017 - tor-commits - lists.torproject.org

[translation/torbutton-torbuttondtd] Update translations for torbutton-torbuttondtd
by translation＠torproject.org 25 Oct '17

25 Oct '17

commit c9256ecf323feed0ba7ff3b76ffd96bb1d5a84c9 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Oct 25 16:47:55 2017 +0000 Update translations for torbutton-torbuttondtd --- nn/torbutton.dtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nn/torbutton.dtd b/nn/torbutton.dtd index 2e743da57..40bcdf962 100644 --- a/nn/torbutton.dtd +++ b/nn/torbutton.dtd @@ -1,6 +1,6 @@ <!ENTITY torbutton.context_menu.new_identity "New Identity"> <!ENTITY torbutton.context_menu.new_identity_key "I"> -<!ENTITY torbutton.context_menu.new_circuit "New Tor Circuit for this Site"> +<!ENTITY torbutton.context_menu.new_circuit "Ny Tor-krets for denne nettstaden"> <!ENTITY torbutton.context_menu.new_circuit_key "C"> <!ENTITY torbutton.context_menu.preferences "Tryggingsinnstillingar"> <!ENTITY torbutton.context_menu.preferences.key "S">

1 0

[torspec/master] Correct the multiplicity of the "a" lines.
by nickm＠torproject.org 25 Oct '17

25 Oct '17

commit f9eeae509344dcfd1f185d0130a0055b00131cea Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Oct 25 12:31:15 2017 -0400 Correct the multiplicity of the "a" lines. These are all "any number" items -- saying "at most once" implies that we should reject consensus or md documents that include them more then once, which isn't true. --- dir-spec.txt | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index a0133d5..7adcd76 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1463,12 +1463,13 @@ "a" SP address ":" port NL - [At most once] + [Any number] - The first advertised IPv6 address for the OR. + Additional advertised addresses for the OR. - Present only if the OR advertises at least one IPv6 address. - Any other IPv4 or IPv6 addresses are ignored. + Present currently only if the OR advertises at least one IPv6 + address; currently, the first address is included and all others are + omitted. Any other IPv4 or IPv6 addresses should be ignored. Address and port are as for "or-address" as specified in section 2.1.1. @@ -2135,13 +2136,13 @@ "a" SP address ":" port NL - [At most once] + [Any number] The first advertised IPv6 address for the OR, if it is reachable. Present only if the OR advertises at least one IPv6 address, and the authority believes that the first advertised address is reachable. - Any other IPv4 or IPv6 addresses are ignored. + Any other IPv4 or IPv6 addresses should be ignored. Address and port are as for "or-address" as specified in section 2.1.1. @@ -3077,11 +3078,13 @@ "a" SP address ":" port NL - [Zero times.] + [Any number] IPv6 ORPorts are contained in microdescriptors and therefore omitted in the microdescriptor consensus. + Not currently generated. + "p" ... NL [Zero times.]

1 0

[tor/maint-0.3.2] hs-v2: Copy needed information between service on prunning
by nickm＠torproject.org 25 Oct '17

25 Oct '17

commit 9592797cf3291fceb7715164e519e02a744c2a25 Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Oct 25 11:21:28 2017 -0400 hs-v2: Copy needed information between service on prunning Turns out that when reloading a tor configured with hidden service(s), we weren't copying all the needed information between the old service object to the new one. For instance, the desc_is_dirty timestamp wasn't which could lead to the service uploading its desriptor much later than it would need to. The replaycache wasn't also moved over and some intro point information as well. Fixes #23790 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug23790 | 6 ++++++ src/or/rendservice.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/changes/bug23790 b/changes/bug23790 new file mode 100644 index 000000000..5ebe77f80 --- /dev/null +++ b/changes/bug23790 @@ -0,0 +1,6 @@ + o Minor bugfixes (hidden service v2): + - When reloading tor (HUP) configured with hidden service(s), some + information weren't copy to the new service object. One problem with + this was that tor would wait at least the RendPostPeriod time before + uploading the descriptor if the reload happened before the descriptor + needed to be published. Fixes bug 23790; bugfix on 0.2.1.9-alpha. diff --git a/src/or/rendservice.c b/src/or/rendservice.c index 74646c78d..60234a5c1 100644 --- a/src/or/rendservice.c +++ b/src/or/rendservice.c @@ -475,6 +475,30 @@ rend_service_port_config_free(rend_service_port_config_t *p) tor_free(p); } +/* Copy relevant data from service src to dst while pruning the service lists. + * This should only be called during the pruning process which takes existing + * services and copy their data to the newly configured services. The src + * service replaycache will be set to NULL after this call. */ +static void +copy_service_on_prunning(rend_service_t *dst, rend_service_t *src) +{ + tor_assert(dst); + tor_assert(src); + + /* Keep the timestamps for when the content changed and the next upload + * time so we can properly upload the descriptor if needed for the new + * service object. */ + dst->desc_is_dirty = src->desc_is_dirty; + dst->next_upload_time = src->next_upload_time; + /* Move the replaycache to the new object. */ + dst->accepted_intro_dh_parts = src->accepted_intro_dh_parts; + src->accepted_intro_dh_parts = NULL; + /* Copy intro point information to destination service. */ + dst->intro_period_started = src->intro_period_started; + dst->n_intro_circuits_launched = src->n_intro_circuits_launched; + dst->n_intro_points_wanted = src->n_intro_points_wanted; +} + /* Helper: Actual implementation of the pruning on reload which we've * decoupled in order to make the unit test workeable without ugly hacks. * Furthermore, this function does NOT free any memory but will nullify the @@ -548,6 +572,10 @@ rend_service_prune_list_impl_(void) smartlist_clear(old->intro_nodes); smartlist_add_all(new->expiring_nodes, old->expiring_nodes); smartlist_clear(old->expiring_nodes); + + /* Copy needed information from old to new. */ + copy_service_on_prunning(new, old); + /* This regular service will survive the closing IPs step after. */ smartlist_add(surviving_services, old); break;

1 0

[tor/master] Merge branch 'maint-0.3.2'
by nickm＠torproject.org 25 Oct '17

25 Oct '17

commit c7a1a987d6dfcb65a5fd639cc3d37b76809c37d5 Merge: 55a3dad70 9592797cf Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Oct 25 12:25:41 2017 -0400 Merge branch 'maint-0.3.2' changes/bug23790 | 6 ++++++ src/or/rendservice.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+)

1 0

[tor/master] hs-v2: Copy needed information between service on prunning
by nickm＠torproject.org 25 Oct '17

25 Oct '17

commit 9592797cf3291fceb7715164e519e02a744c2a25 Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Oct 25 11:21:28 2017 -0400 hs-v2: Copy needed information between service on prunning Turns out that when reloading a tor configured with hidden service(s), we weren't copying all the needed information between the old service object to the new one. For instance, the desc_is_dirty timestamp wasn't which could lead to the service uploading its desriptor much later than it would need to. The replaycache wasn't also moved over and some intro point information as well. Fixes #23790 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug23790 | 6 ++++++ src/or/rendservice.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/changes/bug23790 b/changes/bug23790 new file mode 100644 index 000000000..5ebe77f80 --- /dev/null +++ b/changes/bug23790 @@ -0,0 +1,6 @@ + o Minor bugfixes (hidden service v2): + - When reloading tor (HUP) configured with hidden service(s), some + information weren't copy to the new service object. One problem with + this was that tor would wait at least the RendPostPeriod time before + uploading the descriptor if the reload happened before the descriptor + needed to be published. Fixes bug 23790; bugfix on 0.2.1.9-alpha. diff --git a/src/or/rendservice.c b/src/or/rendservice.c index 74646c78d..60234a5c1 100644 --- a/src/or/rendservice.c +++ b/src/or/rendservice.c @@ -475,6 +475,30 @@ rend_service_port_config_free(rend_service_port_config_t *p) tor_free(p); } +/* Copy relevant data from service src to dst while pruning the service lists. + * This should only be called during the pruning process which takes existing + * services and copy their data to the newly configured services. The src + * service replaycache will be set to NULL after this call. */ +static void +copy_service_on_prunning(rend_service_t *dst, rend_service_t *src) +{ + tor_assert(dst); + tor_assert(src); + + /* Keep the timestamps for when the content changed and the next upload + * time so we can properly upload the descriptor if needed for the new + * service object. */ + dst->desc_is_dirty = src->desc_is_dirty; + dst->next_upload_time = src->next_upload_time; + /* Move the replaycache to the new object. */ + dst->accepted_intro_dh_parts = src->accepted_intro_dh_parts; + src->accepted_intro_dh_parts = NULL; + /* Copy intro point information to destination service. */ + dst->intro_period_started = src->intro_period_started; + dst->n_intro_circuits_launched = src->n_intro_circuits_launched; + dst->n_intro_points_wanted = src->n_intro_points_wanted; +} + /* Helper: Actual implementation of the pruning on reload which we've * decoupled in order to make the unit test workeable without ugly hacks. * Furthermore, this function does NOT free any memory but will nullify the @@ -548,6 +572,10 @@ rend_service_prune_list_impl_(void) smartlist_clear(old->intro_nodes); smartlist_add_all(new->expiring_nodes, old->expiring_nodes); smartlist_clear(old->expiring_nodes); + + /* Copy needed information from old to new. */ + copy_service_on_prunning(new, old); + /* This regular service will survive the closing IPs step after. */ smartlist_add(surviving_services, old); break;

1 0

[tor/release-0.3.2] hs-v2: Copy needed information between service on prunning
by nickm＠torproject.org 25 Oct '17

25 Oct '17

commit 9592797cf3291fceb7715164e519e02a744c2a25 Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Oct 25 11:21:28 2017 -0400 hs-v2: Copy needed information between service on prunning Turns out that when reloading a tor configured with hidden service(s), we weren't copying all the needed information between the old service object to the new one. For instance, the desc_is_dirty timestamp wasn't which could lead to the service uploading its desriptor much later than it would need to. The replaycache wasn't also moved over and some intro point information as well. Fixes #23790 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug23790 | 6 ++++++ src/or/rendservice.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/changes/bug23790 b/changes/bug23790 new file mode 100644 index 000000000..5ebe77f80 --- /dev/null +++ b/changes/bug23790 @@ -0,0 +1,6 @@ + o Minor bugfixes (hidden service v2): + - When reloading tor (HUP) configured with hidden service(s), some + information weren't copy to the new service object. One problem with + this was that tor would wait at least the RendPostPeriod time before + uploading the descriptor if the reload happened before the descriptor + needed to be published. Fixes bug 23790; bugfix on 0.2.1.9-alpha. diff --git a/src/or/rendservice.c b/src/or/rendservice.c index 74646c78d..60234a5c1 100644 --- a/src/or/rendservice.c +++ b/src/or/rendservice.c @@ -475,6 +475,30 @@ rend_service_port_config_free(rend_service_port_config_t *p) tor_free(p); } +/* Copy relevant data from service src to dst while pruning the service lists. + * This should only be called during the pruning process which takes existing + * services and copy their data to the newly configured services. The src + * service replaycache will be set to NULL after this call. */ +static void +copy_service_on_prunning(rend_service_t *dst, rend_service_t *src) +{ + tor_assert(dst); + tor_assert(src); + + /* Keep the timestamps for when the content changed and the next upload + * time so we can properly upload the descriptor if needed for the new + * service object. */ + dst->desc_is_dirty = src->desc_is_dirty; + dst->next_upload_time = src->next_upload_time; + /* Move the replaycache to the new object. */ + dst->accepted_intro_dh_parts = src->accepted_intro_dh_parts; + src->accepted_intro_dh_parts = NULL; + /* Copy intro point information to destination service. */ + dst->intro_period_started = src->intro_period_started; + dst->n_intro_circuits_launched = src->n_intro_circuits_launched; + dst->n_intro_points_wanted = src->n_intro_points_wanted; +} + /* Helper: Actual implementation of the pruning on reload which we've * decoupled in order to make the unit test workeable without ugly hacks. * Furthermore, this function does NOT free any memory but will nullify the @@ -548,6 +572,10 @@ rend_service_prune_list_impl_(void) smartlist_clear(old->intro_nodes); smartlist_add_all(new->expiring_nodes, old->expiring_nodes); smartlist_clear(old->expiring_nodes); + + /* Copy needed information from old to new. */ + copy_service_on_prunning(new, old); + /* This regular service will survive the closing IPs step after. */ smartlist_add(surviving_services, old); break;

1 0

[torspec/master] Add 283: Move IPv6 ORPorts from microdescriptors to the microdesc consensus
by nickm＠torproject.org 25 Oct '17

25 Oct '17

commit 70911f81ea697e22ee1d10e6869349fab555946f Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Oct 25 12:18:14 2017 -0400 Add 283: Move IPv6 ORPorts from microdescriptors to the microdesc consensus --- proposals/000-index.txt | 2 + proposals/283-ipv6-in-micro-consensus.txt | 161 ++++++++++++++++++++++++++++++ 2 files changed, 163 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 8a8d22e..ded6f78 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -203,6 +203,7 @@ Proposals by number: 280 Privacy-Preserving Statistics with Privcount in Tor [DRAFT] 281 Downloading microdescriptors in bulk [DRAFT] 282 Remove "Named" and "Unnamed" handling from consensus voting [OPEN] +283 Move IPv6 ORPorts from microdescriptors to the microdesc consensus [OPEN] Proposals by status: @@ -259,6 +260,7 @@ Proposals by status: 276 Report bandwidth with lower granularity in consensus documents [for 0.3.1.x-alpha] 277 Detect multiple relay instances running with same ID [for 0.3.??] 282 Remove "Named" and "Unnamed" handling from consensus voting [for 0.3.3.x] + 283 Move IPv6 ORPorts from microdescriptors to the microdesc consensus [for 0.3.3.x] ACCEPTED: 172 GETINFO controller option for circuit information 173 GETINFO Option Expansion diff --git a/proposals/283-ipv6-in-micro-consensus.txt b/proposals/283-ipv6-in-micro-consensus.txt new file mode 100644 index 0000000..1334844 --- /dev/null +++ b/proposals/283-ipv6-in-micro-consensus.txt @@ -0,0 +1,161 @@ +Filename: 283-ipv6-in-micro-consensus.txt +Title: Move IPv6 ORPorts from microdescriptors to the microdesc consensus +Author: Tim Wilson-Brown (teor) +Created: 18-Oct-2017 +Status: Open +Target: 0.3.3.x + +1. Summary + + Moving IPv6 ORPorts from microdescs to the microdesc consensus will make + it easier for IPv6 clients to bootstrap and select reachable guards. + + Since consensus method 14, authorities have voted for IPv6 address/port + pairs (ORPorts) in "a" lines. Unreachable IPv6 ORPorts are dropped from the + full consensus. But for clients that use microdescriptors (the default), + IPv6 ORPorts are placed in microdescriptors. So these clients can only tell + if an IPv6 ORPort is unreachable when a majority of voting authorities + mark the relay as not Running. + + This proposal puts reachable relay IPv6 ORPorts in an "a" line in the + microdesc consensus. This allows clients to discover unreachable IPv6 + ORPorts, even if a minority of voting authorities set + AuthDirHasIPv6Connectivity 1. + +2. Proposal + + We add two new consensus methods, here represented as M and N (M < N), to + be allocated when this proposal's implementation is merged. These consensus + methods move IPv6 ORPorts from microdescs to the microdesc consensus. + + We use two different methods because this allows us to modify client code + based on each method. Also, if a bug is discovered in one of the methods, + authorities can be patched to stop voting for it, and then we can implement + a fix in a later method. + +2.1. Add Reachable IPv6 ORPorts to the Microdesc Consensus + + We specify that microdescriptor consensuses created with methods M or later + contain reachable IPv6 ORPorts. + +2.2. Remove IPv6 ORPorts from Microdescriptors + + We specify that microdescriptors created with methods N or later do not + contain any IPv6 ORPorts. + +3. Retaining Existing Behaviour + + The following existing behaviour will be retained: + +3.1. Authority IPv6 Reachability + + Only authorities configured with AuthDirHasIPv6Connectivity 1 will test + IPv6 ORPort reachability, and vote for IPv6 ORPorts. + + This means that: + * if no voting authorities set AuthDirHasIPv6Connectivity 1, there will be + no IPv6 ORPorts in the consensus, + * if a minority of voting authorities set AuthDirHasIPv6Connectivity 1, + unreachable IPv6 ORPort lines will be dropped from the consensus, but the + relay will still be listed as Running, + * if a majority of voting authorities set AuthDirHasIPv6Connectivity 1, + relays with unreachable IPv6 ORPorts will be dropped from the consensus. + + We will document this behaviour in the tor manual page, see #23870. + +3.2. Full Consensus IPv6 ORPorts + + The full consensus will continue to contain reachable IPv6 ORPorts. + +3.3. Clients that use Full Descriptors + + Tor clients that use full descriptors already ignore unreachable IPv6 + ORPorts, and have done so since at least 0.2.8.x. + +4. Impact and Related Changes + +4.1. Directory Authority Configuration + + We will work to get a super-majority (75%) of authorities checking relay + IPv6 reachability, to avoid Running-flag flapping. To do this, authorities + need to get IPv6 connectivity, and set AuthDirHasIPv6Connectivity 1. + +4.2. Relays and Bridges + + Tor relays and bridges do not currently use IPv6 ORPorts from the + consensus. + + We expect that 2/3 of authorities will be voting for consensus method N + before future Tor relay or bridge versions use IPv6 ORPorts from the + consensus. + +4.3. Clients + +4.3.1. Legacy Clients + +4.3.1.1. IPv6 ORPort Circuits + + Tor clients on versions 0.2.8.x to 0.3.2.x check directory documents for + ORPorts in the following order: + * descriptors (routerinfo, available if using bridges or full descriptors) + * consensus (routerstatus) + * microdescriptors (IPv6 ORPorts only) + + Their behaviour will be identical to the current behaviour for consensus + methods M and earlier. When consensus method N is used, they will ignore + unreachable IPv6 ORPorts without any code changes. + +4.3.1.2. IPv6 ORPort Bootstrap + + Tor clients on versions 0.2.8.x and 0.2.9.x are currently unable to + bootstrap over IPv6 only connections when using microdescriptors. This + happens because the microdesc consensus does not contain IPv6 ORPorts. + + When consensus method M is used, they will be able to bootstrap over IPv6 + only connections using microdescriptors, without any code changes. + +4.3.2. Future Clients + +4.3.2.1. Ignoring IPv6 ORPorts in Microdescs + + Tor clients on versions 0.3.3.x and later will ignore unreachable IPv6 + ORPorts once consensus method M or later is in use. (See #23827.) + +4.3.2.2. IPv6 ORPort Bootstrap + + If a bootstrapping IPv6-only client has a consensus made with method M or + later, it should download microdescriptors from one of the IPv6 ORPorts in + that consensus. Previously, IPv6-only clients would use fallback directory + mirrors to download microdescs, because there were no IPv6 ORPorts in the + microdesc consensus. (See #23827.) + +4.3.2.3. Ignoring Addresses in Unused Directory Documents + + If a client doesn't use a particular directory document type for a node, + it should ignore any addresses in that document type. (See #23975.) + +5. Data Size + + This change removes 2-50 bytes from the microdescriptors of relays that + have an IPv6 ORPort, and adds them to reachable IPv6 relays' microdesc + consensus entries. + + As of October 2017, 600 relays (9%) have IPv6 ORPorts in the full + consensus. Their "a" lines take up 19 KB, or 33 bytes each on average. + The microdesc consensus is 1981 KB, so this represents about 1% of its + uncompressed size. + + Most tor clients are already running 0.3.1.7, which implements consensus + diffs. We expect that most directory mirrors will also implement consensus + diffs by the time 2/3 of authorities are voting for consensus method M. + + So we expect that this change will have a minimal impact, which is made + even smaller by compression and consensus diffs. + +6. External Impacts + + We don't expect this change to impact Onionoo and similar projects, because + they typically use the full consensus. + + Metrics doesn't currently graph IPv6 usage in Tor, but would like to in + future.

1 0

[torspec/master] Fix some dir-spec.txt typos and formatting
by nickm＠torproject.org 25 Oct '17

25 Oct '17

commit f57c61a5c5f4e88f84122b92ea544c37270e74e5 Author: teor <teor2345(a)gmail.com> Date: Tue Oct 17 22:19:16 2017 -0400 Fix some dir-spec.txt typos and formatting --- dir-spec.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index dc47829..7654d4a 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2430,7 +2430,7 @@ choose from, authorities should first prefer authorities to non-authorities, then prefer Running to non-Running, and then prefer high-bandwidth to low-bandwidth[*]. To 'disable' a relay, the - authority *should* advertise it without the Running or Valid flag. + authority *should* vote for it without the Running or Valid flag. [*] In this comparison, measured bandwidth is used unless it is not present for a router, in which case advertised bandwidth is used. @@ -2775,7 +2775,7 @@ making changes in the contents of consensus; not for making backward-incompatible changes in their format.) -The following methods have incorrect implementations; authorities SHOULD + The following methods have incorrect implementations; authorities SHOULD NOT advertise support for them: "21" -- Did not correctly enable support for ed25519 key collation.

1 0

[torspec/master] Add descriptions for consensus methods 19 to 21
by nickm＠torproject.org 25 Oct '17

25 Oct '17

commit 57bac0e498e3ad64e25af1fd1a16001eac69c792 Author: teor <teor2345(a)gmail.com> Date: Tue Oct 17 22:19:47 2017 -0400 Add descriptions for consensus methods 19 to 21 And clarify consensus method 18. --- dir-spec.txt | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/dir-spec.txt b/dir-spec.txt index 7654d4a..45726cd 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2631,6 +2631,9 @@ parameters that more than half of the total number of authorities voted for are included in the consensus. + [ As of 0.2.6.1-alpha, authorities no longer advertise or negotiate + any consensus methods lower than 13. ] + * If consensus method 13 or later is used, microdesc consensuses omit any router for which no microdesc was agreed upon. @@ -2651,7 +2654,19 @@ flag to such 'w' lines. * If consensus method 18 or later is used, authorities include - "id" lines in microdescriptors. + "id" lines in microdescriptors. This method adds RSA ids. + + * If consensus method 19 or later is used, authorities may include + "package" lines in consensuses. + + * If consensus method 20 or later is used, authorities may include + GuardFraction information in microdescriptors. + + * If consensus method 21 or later is used, authorities may include + an "id" line for ed25519 identities in microdescriptors. + + [ As of 0.2.8.2-alpha, authorities no longer advertise or negotiate + consensus method 21, because it contains bugs. ] * If consensus method 22 or later is used, and the votes do not produce a majority consensus about a relay's Ed25519 key (see

1 0

[torspec/master] Document the current "or-address" and "a" line implementation
by nickm＠torproject.org 25 Oct '17

25 Oct '17

commit 138ae7f3180f961314df4630b67162cc12369b91 Author: teor <teor2345(a)gmail.com> Date: Tue Oct 17 22:17:27 2017 -0400 Document the current "or-address" and "a" line implementation Preparation for #20916. --- dir-spec.txt | 56 +++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 41 insertions(+), 15 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 45726cd..a0133d5 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -757,8 +757,8 @@ duplicate the address:port pair from its "router" line. The ordering of or-address lines and their PORT entries matter because - Tor MAY accept a limited number of addresses or ports. As of Tor 0.2.3.x - only the first address and the first port are used. + Tor MAY accept a limited number of address/port pairs. As of + Tor 0.2.3.x only the first address/port pair is advertised and used. "tunnelled-dir-server" NL @@ -1463,9 +1463,18 @@ "a" SP address ":" port NL - [Any number] + [At most once] + + The first advertised IPv6 address for the OR. + + Present only if the OR advertises at least one IPv6 address. + Any other IPv4 or IPv6 addresses are ignored. + + Address and port are as for "or-address" as specified in + section 2.1.1. - The "or-address" element as specified in section 2.1.1. + (Only included when generating microdescriptors for + consensus-method 14 or later.) "family" names NL @@ -2126,9 +2135,13 @@ "a" SP address ":" port NL - [Any number.] + [At most once] - Present only if the OR has at least one IPv6 address. + The first advertised IPv6 address for the OR, if it is reachable. + + Present only if the OR advertises at least one IPv6 address, and the + authority believes that the first advertised address is reachable. + Any other IPv4 or IPv6 addresses are ignored. Address and port are as for "or-address" as specified in section 2.1.1. @@ -2156,10 +2169,11 @@ "NoEdConsensus" if any Ed25519 key in the router's descriptor or microdesriptor does not reflect authority consensus. "Stable" if the router is suitable for long-lived circuits. - "Running" if the router is currently usable. Relays without this - flag are omitted from the consensus, and current clients - (since 0.2.9.4-alpha) assume that every listed relay has - this flag. + "Running" if the router is currently usable over the ORPorts that + an authority considers mandatory. Relays without this flag are + omitted from the consensus, and current clients + (since 0.2.9.4-alpha) assume that every listed relay has this + flag. "Valid" if the router has been 'validated'. Clients before 0.2.9.4-alpha would not use routers without this flag by default. Currently, relays without this flag are omitted @@ -2364,7 +2378,12 @@ canonically linked to its public key. "Running" -- A router is 'Running' if the authority managed to connect to - it successfully within the last 45 minutes. + it successfully within the last 45 minutes on the ORPorts it considers + mandatory. Since 0.2.4.x, the mandatory ORPorts are: + * the IPv4 ORPort in the "r" line, and + * the IPv6 ORPort considered for the "a" line, if: + * the router advertises at least one IPv6 ORPort, and + * AuthDirHasIPv6Connectivity 1 is set on the authority "Stable" -- A router is 'Stable' if it is active, and either its Weighted MTBF is at least the median for known active routers or its Weighted MTBF @@ -2637,9 +2656,9 @@ * If consensus method 13 or later is used, microdesc consensuses omit any router for which no microdesc was agreed upon. - * If consensus method 14 or later is used, votes and - consensuses may include "a" lines listing additional OR - ports. + * If consensus method 14 or later is used, the ns consensus and + microdescriptors may include an "a" line for each router, listing + an IPv6 OR port. * If consensus method 15 or later is used, microdescriptors include "p6" lines including IPv6 exit policies. @@ -2757,7 +2776,7 @@ "11" -- Don't consider BadExits when calculating bandwidth weights "12" -- Params are only included if enough auths voted for them "13" -- Omit router entries with missing microdescriptors. - "14" -- Adds support for "a" lines. + "14" -- Adds support for "a" lines in ns consensues and microdescriptors. "15" -- Adds support for "p6" lines. "16" -- Adds ntor keys to microdescriptors "17" -- Adds "Unmeasured=1" flags to "w" lines @@ -3056,6 +3075,13 @@ Similar to "r" lines in section 3.4.1, but without the digest element. + "a" SP address ":" port NL + + [Zero times.] + + IPv6 ORPorts are contained in microdescriptors and therefore omitted + in the microdescriptor consensus. + "p" ... NL [Zero times.]

1 0