tor-commits January 2014

tor-commits@lists.torproject.org

23 participants
2271 discussions

[torspec/master] Fix section numbers from copying 4.3 after 3.5.
by nickm＠torproject.org 17 Jan '14

17 Jan '14

commit 6bc07485c734d00145df115aa69e851b5c328e4a Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 14 12:32:42 2014 +0100 Fix section numbers from copying 4.3 after 3.5. --- dir-spec.txt | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index ad59fcd..4fc8fdd 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -482,7 +482,7 @@ [At most once.] - An exit-policy summary as specified in sections 3.4.1 and 3.6.2, + An exit-policy summary as specified in sections 3.4.1 and 3.7.2, summarizing the router's rules for connecting to IPv6 addresses. A missing "ipv6-policy" line is equivalent to "ipv6-policy reject 1-65535". @@ -1185,7 +1185,7 @@ [At most once] - The exit-policy summary as specified in sections 3.4.1 and 3.6.2. A + The exit-policy summary as specified in sections 3.4.1 and 3.7.2. A missing "p" line is equivalent to "p reject 1-65535". [With microdescriptors, clients don't learn exact exit policies: @@ -1197,7 +1197,7 @@ [At most once] - The IPv6 exit policy summary as specified in sections 3.4.1 and 3.6.2. A + The IPv6 exit policy summary as specified in sections 3.4.1 and 3.7.2. A missing "p6" line is equivalent to "p6 reject 1-65535". (Only included when generating microdescriptors for @@ -1287,7 +1287,7 @@ [At most once for votes; does not occur in consensuses.] A space-separated list of supported methods for generating - consensuses from votes. See section 3.6.1 for details. If this + consensuses from votes. See section 3.7.1 for details. If this line is present, method "1" MUST be included. Absence of the line means that only method "1" is supported. @@ -1295,7 +1295,7 @@ [At most once for consensuses; does not occur in votes.] - See section 3.6.1 for details. + See section 3.7.1 for details. (Only included when the vote is generated with consensus-method 2 or later.) @@ -1724,7 +1724,7 @@ Wbe - Weight for Exit-flagged nodes for BEGIN_DIR requests Wbd - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests - These values are calculated as specified in section 3.6.3. + These values are calculated as specified in section 3.7.3. The signature contains the following item, which appears Exactly Once for a vote, and At Least Once for a consensus. @@ -1897,13 +1897,13 @@ accept not for all addresses, ignoring all rejects for private netblocks. "Most" addresses are permitted if no more than 2^25 IPv4 addresses (two /8 networks) were blocked. The list is encoded - as described in section 3.6.2. + as described in section 3.7.2. 3.5. Downloading missing certificates XXX when to download certificates. -4.3. Downloading and storing router descriptors (authorities and caches) +3.6. Downloading router descriptors Periodically (currently, every 10 seconds), directory servers check whether there are any specific descriptors that they do not have and that @@ -1937,7 +1937,7 @@ Authorities SHOULD NOT download descriptors for routers that they would immediately reject for reasons listed in section 3.2. -3.6. Computing a consensus from a set of votes +3.7. Computing a consensus from a set of votes Given a set of votes, authorities compute the contents of the consensus document as follows: @@ -2020,7 +2020,7 @@ for the descriptor we are listing. (They should all be the same. If they are not, we pick the most commonly listed one, breaking ties in favor of the lexicographically larger - vote.) The port list is encoded as specified in section 3.6.2. + vote.) The port list is encoded as specified in section 3.7.2. * If consensus-method 6 or later is in use and if 3 or more authorities provide a Measured= keyword in their votes for @@ -2064,7 +2064,7 @@ All ties in computing medians are broken in favor of the smaller or earlier item. -3.6.1. Forward compatibility +3.7.1. Forward compatibility Future versions of Tor will need to include new information in the consensus documents, but it is important that all authorities (or at least @@ -2102,7 +2102,7 @@ making changes in the contents of consensus; not for making backward-incompatible changes in their format.) -3.6.2. Encoding port lists +3.7.2. Encoding port lists Whether the summary shows the list of accepted ports or the list of rejected ports depends on which list is shorter (has a shorter string @@ -2122,7 +2122,7 @@ use an accept-style summary and list as much of the port list as is possible within these 1000 bytes. [XXXX be more specific.] -3.6.3. Computing Bandwidth Weights +3.7.3. Computing Bandwidth Weights Let weight_scale = 10000 @@ -2284,7 +2284,7 @@ Handle bridges and strange exit policies: Wgm=Wgg, Wem=Wee, Weg=Wed -3.7. Consensus flavors +3.8. Consensus flavors Consensus flavors are variants of the consensus that clients can choose to download and use instead of the unflavored consensus. The purpose @@ -2300,7 +2300,7 @@ Examples for consensus flavors include: - Publishing hashes of microdescriptors instead of hashes of - full descriptors (see section 3.7.2). + full descriptors (see section 3.8.2). - Including different digests of descriptors, instead of the perhaps-soon-to-be-totally-broken SHA1. @@ -2321,7 +2321,7 @@ "network-status-version" SP version SP flavor NL -3.7.1. ns consensus +3.8.1. ns consensus The ns consensus flavor is equivalent to the unflavored consensus except for its first line which states its consensus flavor name: @@ -2330,7 +2330,7 @@ [At start, exactly once.] -3.7.2. Microdescriptor consensus +3.8.2. Microdescriptor consensus The microdescriptor consensus is a consensus flavor that contains microdescriptor hashes instead of descriptor hashes and that omits @@ -2386,7 +2386,7 @@ Additionally, a microdescriptor consensus MAY use the sha256 digest algorithm for its signatures. -3.8. Detached signatures +3.9. Detached signatures Assuming full connectivity, every authority should compute and sign the same consensus including any flavors in each period. Therefore, it

1 0

[torspec/master] Copy 4.5 "Downloading extra-info documents" after 3.6
by nickm＠torproject.org 17 Jan '14

17 Jan '14

commit b6eaf2ef87bba3bffa22a95976c4d7511fcd0bd9 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 14 12:45:26 2014 +0100 Copy 4.5 "Downloading extra-info documents" after 3.6 This commit does not yet repair section numbering or references. --- dir-spec.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/dir-spec.txt b/dir-spec.txt index 0082443..094211e 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1935,6 +1935,22 @@ Authorities SHOULD NOT download descriptors for routers that they would immediately reject for reasons listed in section 3.2. +4.5. Downloading and storing extra-info documents + + All authorities, and any cache that chooses to cache extra-info documents, + and any client that uses extra-info documents, should implement this + section. + + Note that generally, clients don't need extra-info documents. + + Periodically, the Tor instance checks whether it is missing any extra-info + documents: in other words, if it has any router descriptors with an + extra-info-digest field that does not match any of the extra-info + documents currently held. If so, it downloads whatever extra-info + documents are missing. Caches download from authorities; non-caches try + to download from caches. We follow the same splitting and back-off rules + as in section 4.3 (if a cache) or section 5.3 (if a client). + 3.7. Computing a consensus from a set of votes Given a set of votes, authorities compute the contents of the consensus

1 0

[torspec/master] Rename section 3.10.
by nickm＠torproject.org 17 Jan '14

17 Jan '14

commit d43f9accf9091c348e60762b2102324bffebaf53 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 14 13:42:52 2014 +0100 Rename section 3.10. --- dir-spec.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dir-spec.txt b/dir-spec.txt index 1fe0a25..11392b6 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2393,7 +2393,7 @@ Additionally, a microdescriptor consensus MAY use the sha256 digest algorithm for its signatures. -3.10. Detached signatures +3.10. Exchanging detached signatures Assuming full connectivity, every authority should compute and sign the same consensus including any flavors in each period. Therefore, it

1 0

[torspec/master] Fix section numbers from copying 4.5 after 3.6.
by nickm＠torproject.org 17 Jan '14

17 Jan '14

commit de2ae076f9ca6e1e4a24690977471db4f7483eed Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 14 12:49:04 2014 +0100 Fix section numbers from copying 4.5 after 3.6. --- dir-spec.txt | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 094211e..5fa8bc0 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -482,7 +482,7 @@ [At most once.] - An exit-policy summary as specified in sections 3.4.1 and 3.7.2, + An exit-policy summary as specified in sections 3.4.1 and 3.8.2, summarizing the router's rules for connecting to IPv6 addresses. A missing "ipv6-policy" line is equivalent to "ipv6-policy reject 1-65535". @@ -1185,7 +1185,7 @@ [At most once] - The exit-policy summary as specified in sections 3.4.1 and 3.7.2. A + The exit-policy summary as specified in sections 3.4.1 and 3.8.2. A missing "p" line is equivalent to "p reject 1-65535". [With microdescriptors, clients don't learn exact exit policies: @@ -1197,7 +1197,7 @@ [At most once] - The IPv6 exit policy summary as specified in sections 3.4.1 and 3.7.2. A + The IPv6 exit policy summary as specified in sections 3.4.1 and 3.8.2. A missing "p6" line is equivalent to "p6 reject 1-65535". (Only included when generating microdescriptors for @@ -1287,7 +1287,7 @@ [At most once for votes; does not occur in consensuses.] A space-separated list of supported methods for generating - consensuses from votes. See section 3.7.1 for details. If this + consensuses from votes. See section 3.8.1 for details. If this line is present, method "1" MUST be included. Absence of the line means that only method "1" is supported. @@ -1295,7 +1295,7 @@ [At most once for consensuses; does not occur in votes.] - See section 3.7.1 for details. + See section 3.8.1 for details. (Only included when the vote is generated with consensus-method 2 or later.) @@ -1724,7 +1724,7 @@ Wbe - Weight for Exit-flagged nodes for BEGIN_DIR requests Wbd - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests - These values are calculated as specified in section 3.7.3. + These values are calculated as specified in section 3.8.3. The signature contains the following item, which appears Exactly Once for a vote, and At Least Once for a consensus. @@ -1897,7 +1897,7 @@ accept not for all addresses, ignoring all rejects for private netblocks. "Most" addresses are permitted if no more than 2^25 IPv4 addresses (two /8 networks) were blocked. The list is encoded - as described in section 3.7.2. + as described in section 3.8.2. 3.5. Downloading missing certificates @@ -1935,7 +1935,7 @@ Authorities SHOULD NOT download descriptors for routers that they would immediately reject for reasons listed in section 3.2. -4.5. Downloading and storing extra-info documents +3.7. Downloading extra-info documents All authorities, and any cache that chooses to cache extra-info documents, and any client that uses extra-info documents, should implement this @@ -1951,7 +1951,7 @@ to download from caches. We follow the same splitting and back-off rules as in section 4.3 (if a cache) or section 5.3 (if a client). -3.7. Computing a consensus from a set of votes +3.8. Computing a consensus from a set of votes Given a set of votes, authorities compute the contents of the consensus document as follows: @@ -2034,7 +2034,7 @@ for the descriptor we are listing. (They should all be the same. If they are not, we pick the most commonly listed one, breaking ties in favor of the lexicographically larger - vote.) The port list is encoded as specified in section 3.7.2. + vote.) The port list is encoded as specified in section 3.8.2. * If consensus-method 6 or later is in use and if 3 or more authorities provide a Measured= keyword in their votes for @@ -2078,7 +2078,7 @@ All ties in computing medians are broken in favor of the smaller or earlier item. -3.7.1. Forward compatibility +3.8.1. Forward compatibility Future versions of Tor will need to include new information in the consensus documents, but it is important that all authorities (or at least @@ -2116,7 +2116,7 @@ making changes in the contents of consensus; not for making backward-incompatible changes in their format.) -3.7.2. Encoding port lists +3.8.2. Encoding port lists Whether the summary shows the list of accepted ports or the list of rejected ports depends on which list is shorter (has a shorter string @@ -2136,7 +2136,7 @@ use an accept-style summary and list as much of the port list as is possible within these 1000 bytes. [XXXX be more specific.] -3.7.3. Computing Bandwidth Weights +3.8.3. Computing Bandwidth Weights Let weight_scale = 10000 @@ -2298,7 +2298,7 @@ Handle bridges and strange exit policies: Wgm=Wgg, Wem=Wee, Weg=Wed -3.8. Consensus flavors +3.9. Consensus flavors Consensus flavors are variants of the consensus that clients can choose to download and use instead of the unflavored consensus. The purpose @@ -2314,7 +2314,7 @@ Examples for consensus flavors include: - Publishing hashes of microdescriptors instead of hashes of - full descriptors (see section 3.8.2). + full descriptors (see section 3.9.2). - Including different digests of descriptors, instead of the perhaps-soon-to-be-totally-broken SHA1. @@ -2335,7 +2335,7 @@ "network-status-version" SP version SP flavor NL -3.8.1. ns consensus +3.9.1. ns consensus The ns consensus flavor is equivalent to the unflavored consensus except for its first line which states its consensus flavor name: @@ -2344,7 +2344,7 @@ [At start, exactly once.] -3.8.2. Microdescriptor consensus +3.9.2. Microdescriptor consensus The microdescriptor consensus is a consensus flavor that contains microdescriptor hashes instead of descriptor hashes and that omits @@ -2400,7 +2400,7 @@ Additionally, a microdescriptor consensus MAY use the sha256 digest algorithm for its signatures. -3.9. Detached signatures +3.10. Detached signatures Assuming full connectivity, every authority should compute and sign the same consensus including any flavors in each period. Therefore, it

1 0

[torspec/master] Move client-specific parts of 4.4 to 5.4.
by nickm＠torproject.org 17 Jan '14

17 Jan '14

commit 6eb9f849f8ff455125cd6a77ca4fb587f57c5a33 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 14 15:33:59 2014 +0100 Move client-specific parts of 4.4 to 5.4. --- dir-spec.txt | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 3ae0162..17b694e 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2571,19 +2571,15 @@ 4.4. Downloading extra-info documents - Any cache that chooses to cache extra-info documents - and any client that uses extra-info documents should implement this + Any cache that chooses to cache extra-info documents should implement this section. - Note that generally, clients don't need extra-info documents. - Periodically, the Tor instance checks whether it is missing any extra-info documents: in other words, if it has any router descriptors with an extra-info-digest field that does not match any of the extra-info documents currently held. If so, it downloads whatever extra-info - documents are missing. Caches download from authorities; non-caches try - to download from caches. We follow the same splitting and back-off rules - as in section 4.2 (if a cache) or section 5.3 (if a client). + documents are missing. Caches download from authorities. We follow the + same splitting and back-off rules as in section 4.2. 4.5. General-use HTTP URLs @@ -2824,6 +2820,20 @@ or less than the download bandwidth for the microdescriptors they do not want. +5.4. Downloading extra-info documents + + Any client that uses extra-info documents should implement this + section. + + Note that generally, clients don't need extra-info documents. + + Periodically, the Tor instance checks whether it is missing any extra-info + documents: in other words, if it has any router descriptors with an + extra-info-digest field that does not match any of the extra-info + documents currently held. If so, it downloads whatever extra-info + documents are missing. Clients try to download from caches. + We follow the same splitting and back-off rules as in section 5.3. + 6. Using directory information Everyone besides directory authorities uses the approaches in this section

1 0

[torspec/master] Rename section 3.9.
by nickm＠torproject.org 17 Jan '14

17 Jan '14

commit 7ea6c1c6c9131f65dff4acf1ade0457b67993e8f Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 14 13:37:27 2014 +0100 Rename section 3.9. --- dir-spec.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dir-spec.txt b/dir-spec.txt index c79d4a6..1fe0a25 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2291,7 +2291,7 @@ Handle bridges and strange exit policies: Wgm=Wgg, Wem=Wee, Weg=Wed -3.9. Consensus flavors +3.9. Computing consensus flavors Consensus flavors are variants of the consensus that clients can choose to download and use instead of the unflavored consensus. The purpose

1 0

[torspec/master] Clean up copied section 3.7 and section 4.5.
by nickm＠torproject.org 17 Jan '14

17 Jan '14

commit 6068678828552d50e751188dcc02284a679f25cb Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 14 13:33:33 2014 +0100 Clean up copied section 3.7 and section 4.5. Section 3.7 should only contain parts that are relevant for authorities, and section 4.5 should only contain parts that are relevant for caches (right now, it also describes what clients should do, but that's something to change when cleaning up 4.5). --- dir-spec.txt | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 5fa8bc0..c79d4a6 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1937,19 +1937,12 @@ 3.7. Downloading extra-info documents - All authorities, and any cache that chooses to cache extra-info documents, - and any client that uses extra-info documents, should implement this - section. - - Note that generally, clients don't need extra-info documents. - - Periodically, the Tor instance checks whether it is missing any extra-info + Periodically, an authority checks whether it is missing any extra-info documents: in other words, if it has any router descriptors with an extra-info-digest field that does not match any of the extra-info documents currently held. If so, it downloads whatever extra-info - documents are missing. Caches download from authorities; non-caches try - to download from caches. We follow the same splitting and back-off rules - as in section 4.3 (if a cache) or section 5.3 (if a client). + documents are missing. We follow the same splitting and back-off rules + as in section 3.6. 3.8. Computing a consensus from a set of votes @@ -2574,8 +2567,8 @@ 4.5. Downloading and storing extra-info documents - All authorities, and any cache that chooses to cache extra-info documents, - and any client that uses extra-info documents, should implement this + Any cache that chooses to cache extra-info documents + and any client that uses extra-info documents should implement this section. Note that generally, clients don't need extra-info documents.

1 0

[torspec/master] Rename section 4.1 and make it cache-only.
by nickm＠torproject.org 17 Jan '14

17 Jan '14

commit 2132556ca8c82324a25b6a5a890174c43b94e830 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 14 14:06:05 2014 +0100 Rename section 4.1 and make it cache-only. --- dir-spec.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 765d076..dbf48d0 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2501,9 +2501,9 @@ All directory caches implement this section, except as noted. -4.1. Downloading consensus status documents (caches only) +4.1. Downloading consensus status documents - All directory servers (authorities and caches) try to keep a recent + All directory caches try to keep a recent network-status consensus document to serve to clients. A cache ALWAYS downloads a network-status consensus if any of the following are true: - The cache has no consensus document.

1 0

[torspec/master] Distribute what's left over from 4.1 to 3.*.
by nickm＠torproject.org 17 Jan '14

17 Jan '14

commit 9c555dd4ed36ffa0862fe5ef15909cea59fbfae2 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 14 13:54:28 2014 +0100 Distribute what's left over from 4.1 to 3.*. Section 4.1 "Voting" describes much more than just the voting operation. Move these operation fragments to the subsections they belong in. --- dir-spec.txt | 57 ++++++++++++++++++++++++++++++++------------------------- 1 file changed, 32 insertions(+), 25 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 11392b6..144af92 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1946,8 +1946,13 @@ 3.8. Computing a consensus from a set of votes - Given a set of votes, authorities compute the contents of the consensus - document as follows: + Given a set of votes, authorities compute the contents of the consensus. + + The consensus status, along with as many signatures as the server + currently knows (see section 3.10 below), should be available at + http://<hostname>/tor/status-vote/next/consensus.z + + The contents of the consensus document are as follows: The "valid-after", "valid-until", and "fresh-until" times are taken as the median of the respective values from all the votes. @@ -2395,6 +2400,17 @@ 3.10. Exchanging detached signatures + Once an authority has computed and signed a consensus network status, it + should send its detached signature to each other authority in an HTTP POST + request to the URL: + http://<hostname>/tor/post/consensus-signature + + [XXX Note why we support push-and-then-pull.] + + All of the detached signatures it knows for consensus status should be + available at: + http://<hostname>/tor/status-vote/next/consensus-signatures.z + Assuming full connectivity, every authority should compute and sign the same consensus including any flavors in each period. Therefore, it isn't necessary to download the consensus or any flavors of it computed @@ -2454,19 +2470,7 @@ [As in the consensus; the signature object is the same as in the consensus document.] -4. Directory server operation - - All directory authorities and directory caches ("directory servers") - implement this section, except as noted. - -4.1. Voting (authorities only) - - The consensus status, along with as many signatures as the server - currently knows, should be available at - http://<hostname>/tor/status-vote/next/consensus.z - All of the detached signatures it knows for consensus status should be - available at: - http://<hostname>/tor/status-vote/next/consensus-signatures.z +3.11. Publishing the signed consensus Once there are enough signatures, or once the voting period starts, these documents are available at @@ -2475,6 +2479,12 @@ http://<hostname>/tor/status-vote/current/consensus-signatures.z [XXX current/consensus-signatures is not currently implemented, as it is not used in the voting protocol.] + [XXX It's actually false that the first document is available as soon + as there are enough signatures. It's only available as soon as the + voting period starts. -KL] + + [XXX possible future features include support for downloading old + consensuses.] The other vote documents are analogously made available under http://<hostname>/tor/status-vote/current/authority.z @@ -2482,21 +2492,18 @@ http://<hostname>/tor/status-vote/current/d/<d>.z once the consensus is complete. - Once an authority has computed and signed a consensus network status, it - should send its detached signature to each other authority in an HTTP POST - request to the URL: - http://<hostname>/tor/post/consensus-signature - - [XXX Note why we support push-and-then-pull.] - - [XXX possible future features include support for downloading old - consensuses.] - The authorities serve another consensus of each flavor "F" from the locations /tor/status-vote/(current|next)/consensus-F.z. and /tor/status-vote/(current|next)/consensus-F/<FP1>+....z. +4. Directory server operation + + All directory authorities and directory caches ("directory servers") + implement this section, except as noted. + +4.1. Voting (authorities only) + 4.2. Downloading consensus status documents (caches only) All directory servers (authorities and caches) try to keep a recent

1 0

[torspec/master] Rename section 4.
by nickm＠torproject.org 17 Jan '14

17 Jan '14

commit a610e5ffb4b864c38da6433d9869336e2e75ac23 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jan 14 14:01:58 2014 +0100 Rename section 4. --- dir-spec.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 144af92..e4e2f4a 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2497,10 +2497,9 @@ /tor/status-vote/(current|next)/consensus-F.z. and /tor/status-vote/(current|next)/consensus-F/<FP1>+....z. -4. Directory server operation +4. Directory cache operation - All directory authorities and directory caches ("directory servers") - implement this section, except as noted. + All directory caches implement this section, except as noted. 4.1. Voting (authorities only)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits January 2014