tor-commits December 2017

tor-commits@lists.torproject.org

14 participants
2422 discussions

[webwml/master] Add sections for trac (#18586) and reporting bad relays (#22412).
by hiro＠torproject.org 04 Dec '17

04 Dec '17

commit 9f5f29d3b01135ff66317af76046208a902a2cd3 Author: kat <kat(a)torproject.org> Date: Sun Dec 3 14:59:18 2017 -0500 Add sections for trac (#18586) and reporting bad relays (#22412). Add sections. Move security section to directly follow trac section. --- about/en/contact.wml | 42 +++++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) diff --git a/about/en/contact.wml b/about/en/contact.wml index 6105e9cb..2c7348f7 100644 --- a/about/en/contact.wml +++ b/about/en/contact.wml @@ -16,9 +16,11 @@ <li><a href="#support">Support</a></li> <li><a href="#irc">IRC</a></li> <li><a href="#twitter">Twitter</a></li> + <li><a href="#bugs">Bug Tracker</a></li> + <li><a href="#security">Security Issues</a></li> + <li><a href="#badrelays">Report Bad Relays</a></li> <li><a href="#email">Email</a></li> <li><a href="#mail">Mailing Address</a></li> - <li><a href="#security">Security Issues</a></li> </ul> <a id="support"></a> @@ -88,7 +90,34 @@ </ul> </p> - <a id="email"></a> + <a id="bugs"></a> + <h3><a class="anchor" href="#bugs">Bug Tracker</a></h3> + <p>You can report bugs other than <a href="#security">security + issues</a> using our <a href="https://trac.torproject.org/projects/tor" + >bug tracker</a>. Our + <a href="<page getinvolved/volunteer>">volunteer page</a> has + convenient links to <a href="<page getinvolved/volunteer>#Projects"> + project-related queries</a>.</p> + + <a id="security"></a> + <h3><a class="anchor" href="#security">Security Issues</a></h3> + <p>If you've found a security issue in one of our projects or our + infrastructure, please email the respective maintainer. You can find + their GPG fingerprint/key on our <a + href="https://db.torproject.org">developer ldap search page</a>. Due + to the many different projects we have, we do not offer a single + list for security issues.</p> + + <a id="badrelays"></a> + <h3><a class="anchor" href="#badrelays">Report Bad Relays</a></h3> + <p>If you find a relay that you think is malicious, misconfigured, + or otherwise broken, please check out our + <a href="https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays"> + wiki page</a> and <a href="https://blog.torproject.org/how-report-bad-relays" + >blog post</a> on how to report it.</p> + + + <a id="email"></a> <h3><a class="anchor" href="#email">Email</a></h3> <p>If you have Tor questions, please try to help yourself via the above support venues. Please don't use this contact address @@ -116,15 +145,6 @@ Seattle, WA 98194 USA<br><br> </address> - <a id="security"></a> - <h3><a class="anchor" href="#security">Security Issues</a></h3> - <p>If you've found a security issue in one of our projects or our - infrastructure, please email the respective maintainer. You can find - their GPG fingerprint/key on our <a - href="https://db.torproject.org">developer ldap search page</a>. Due - to the many different projects we have, we do not offer a single - list for security issues. - </div>  <div id = "sidecol">

1 0

[webwml/master] Merge remote-tracking branch 'kat/tor-users-dead-links'
by hiro＠torproject.org 04 Dec '17

04 Dec '17

commit bc2c344347a0d69af008941580a7c4c0c5f787ff Merge: 9f5f29d3 8d7dd7b6 Author: hiromipaw <hiro(a)torproject.org> Date: Mon Dec 4 18:16:51 2017 +0100 Merge remote-tracking branch 'kat/tor-users-dead-links' about/en/torusers.wml | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-)

1 0

[torspec/master] Add consensus method 28, which removes IPv6 addresses from microdescriptors
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit 52e70bd5064bd50ee1d84e810d3eeafd4092b246 Author: teor <teor2345(a)gmail.com> Date: Tue Oct 17 22:42:52 2017 -0400 Add consensus method 28, which removes IPv6 addresses from microdescriptors Documents #23828. --- dir-spec.txt | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 7b636c4..5cf9770 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1475,7 +1475,7 @@ section 2.1.1. (Only included when generating microdescriptors for - consensus-method 14 or later.) + consensus-methods 14 to 27.) "family" names NL @@ -2386,10 +2386,10 @@ * the router advertises at least one IPv6 ORPort, and * AuthDirHasIPv6Connectivity 1 is set on the authority. A minority of voting authorities that set AuthDirHasIPv6Connectivity will - drop unreachable IPv6 ORPorts from the full consensus. But they can not - drop IPv6 ORPorts from microdescriptors. Consensus method 27 in 0.3.3.x - puts IPv6 ORPorts in the microdesc consensus, so that authorities can - drop unreachable IPv6 ORPorts from all consensus flavours. + drop unreachable IPv6 ORPorts from the full consensus. Consensus method 27 + in 0.3.3.x puts IPv6 ORPorts in the microdesc consensus, so that + authorities can drop unreachable IPv6 ORPorts from all consensus flavours. + Consensus method 28 removes IPv6 ORPorts from microdescriptors. "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 @@ -2717,6 +2717,9 @@ * If consensus method 27 or later is used, the microdesc consensus may include an "a" line for each router, listing an IPv6 OR port. + * If consensus method 28 or later is used, microdescriptors no longer + include "a" lines. + The signatures at the end of a consensus document are sorted in ascending order by identity digest. @@ -2799,6 +2802,7 @@ "25" -- Vote on recommended-protocols and required-protocols. "26" -- Initialize bandwidth weights to 1 to avoid division-by-zero. "27" -- Adds support for "a" lines in microdescriptor consensues. + "28" -- Removes "a" lines from microdescriptors. Before generating a consensus, an authority must decide which consensus method to use. To do this, it looks for the highest version number

1 0

[torspec/master] Revise proposal 283 based on Nick's feedback
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit b523c5c4882ce13a5d9efe6f330b0f7d1d0b1167 Author: teor <teor2345(a)gmail.com> Date: Wed Nov 22 00:21:08 2017 +1100 Revise proposal 283 based on Nick's feedback --- proposals/283-ipv6-in-micro-consensus.txt | 109 ++++++++++++++++++------------ 1 file changed, 67 insertions(+), 42 deletions(-) diff --git a/proposals/283-ipv6-in-micro-consensus.txt b/proposals/283-ipv6-in-micro-consensus.txt index db57176..da12cfa 100644 --- a/proposals/283-ipv6-in-micro-consensus.txt +++ b/proposals/283-ipv6-in-micro-consensus.txt @@ -1,6 +1,6 @@ Filename: 283-ipv6-in-micro-consensus.txt Title: Move IPv6 ORPorts from microdescriptors to the microdesc consensus -Author: Tim Wilson-Brown (teor) +Author: Tim Wilson-Brown (teor), Nick Mathewson Created: 18-Oct-2017 Status: Open Target: 0.3.3.x @@ -10,16 +10,21 @@ Target: 0.3.3.x 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. + Tor clients on IPv6-only connections currently have to use IPv6 Fallback + Directory Mirrors to fetch their microdescriptors. This does not scale + well. After this change, they will be able to fetch microdescriptors from + any IPv6-enabled directory mirror in the consensus. - 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 + 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. After + this consensus change, they will be able to bootstrap without any client + code changes. + + For clients that use microdescriptors (the default), IPv6 ORPorts are + always 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. After this proposal, clients will be able to discover + unreachable ORPorts, even if a minority of voting authorities set AuthDirHasIPv6Connectivity 1. 2. Proposal @@ -40,8 +45,8 @@ Target: 0.3.3.x 2.2. Remove IPv6 ORPorts from Microdescriptors - We specify that microdescriptors created with methods N or later do not - contain any IPv6 ORPorts. + We specify that microdescriptors created with methods N or later start + omitting IPv6 ORPorts. 3. Retaining Existing Behaviour @@ -55,22 +60,22 @@ Target: 0.3.3.x 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 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, and + reachable IPv6 ORPort lines will be included in the consensus. * if a majority of voting authorities set AuthDirHasIPv6Connectivity 1, - relays with unreachable IPv6 ORPorts will be dropped from the consensus. + relays with unreachable IPv6 ORPorts will not be listed as Running. + Reachable IPv6 ORPort lines will be included in the consensus. + (To ensure that any valid majority will vote relays with unreachable + IPv6 ORPorts not Running, 75% of authorities must set + AuthDirHasIPv6Connectivity 1.) 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 +3.2. NS Consensus IPv6 ORPorts - Tor clients that use full descriptors already ignore unreachable IPv6 - ORPorts, and have done so since at least 0.2.8.x. + The NS consensus will continue to contain reachable IPv6 ORPorts. 4. Impact and Related Changes @@ -103,36 +108,44 @@ Target: 0.3.3.x 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. + unreachable IPv6 ORPorts without any code changes, as long as they are + using microdescriptors. 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 + bootstrap over IPv6-only connections when using microdescriptors. This happens because the microdesc consensus does not contain IPv6 ORPorts. + (IPv6-only Tor clients on versions 0.3.0.2-alpha and later use fallback + directory mirrors to fetch their microdescriptors.) - When consensus method M is used, they will be able to bootstrap over IPv6 - only connections using microdescriptors, without any code changes. + When consensus method M is used, 0.2.8.x and 0.2.9.x clients 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.) + ORPorts once consensus method M or later is in use. This requires some code + changes, 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 + that consensus. This requires some code changes, see #23827. + + Previously, IPv6-only clients would use fallback directory mirrors to download microdescs, because there were no IPv6 ORPorts in the - microdesc consensus. (See #23827.) + microdesc consensus. 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.) + it should ignore any addresses in that document type. This requires some + code changes, see #23975. 5. Data Size @@ -140,22 +153,34 @@ Target: 0.3.3.x 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 + As of October 2017, 600 relays (9%) have IPv6 ORPorts in the NS 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. + The gzip-compressed microdesc consensus is 564 KB, and adding the existing + IPv6 addresses makes it 576 KB (a 2.1% increase). Adding IPv6 addresses to + every relay makes it 644 KB (a 14% increase). zstd-compressed microdesc + consensuses show smaller increases of 1.7% and 8.0%, respectively. - So we expect that this change will have a minimal impact, which is made - even smaller by compression and consensus diffs. + Most tor clients are already running 0.3.1.7, which implements consensus + diffs and zstd compression. We expect that most directory mirrors will also + implement consensus diffs and zstd compression by the time 2/3 of + authorities are voting for consensus method M. Consensus diffs will reduce + the worst-case impact of this change for clients and relays that have a + recent consensus. 6. External Impacts We don't expect this change to impact Onionoo and similar projects, because - they typically use the full consensus. + they typically use the NS consensus. + +7. Monitoring + + OnionOO has implemented an "unreachable IPv6 address" attribute: + https://trac.torproject.org/projects/tor/ticket/21637 + + Metrics is working on IPv6 relay graphs: + https://trac.torproject.org/projects/tor/ticket/23761 - Metrics doesn't currently graph IPv6 usage in Tor, but would like to in - future. + Consensus-health implements a ReachableIPv6 pseudo-flag for authorities + and relays: + https://consensus-health.torproject.org/

1 0

[torspec/master] Add consensus method 27, which adds IPv6 addresses to the micro consensus
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit fdc8f3e8c627cbd35c501f77cf81ebcaea70a3a6 Author: teor <teor2345(a)gmail.com> Date: Tue Oct 17 22:32:31 2017 -0400 Add consensus method 27, which adds IPv6 addresses to the micro consensus Documents #23826. --- dir-spec.txt | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 846f7a9..7b636c4 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2386,8 +2386,10 @@ * the router advertises at least one IPv6 ORPort, and * AuthDirHasIPv6Connectivity 1 is set on the authority. A minority of voting authorities that set AuthDirHasIPv6Connectivity will - drop unreachable IPv6 addresses from the full consensus. But they can not - drop IPv6 addresses from microdescriptors. + drop unreachable IPv6 ORPorts from the full consensus. But they can not + drop IPv6 ORPorts from microdescriptors. Consensus method 27 in 0.3.3.x + puts IPv6 ORPorts in the microdesc consensus, so that authorities can + drop unreachable IPv6 ORPorts from all consensus flavours. "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 @@ -2712,6 +2714,9 @@ bandwith weights to 1 in our calculations, to avoid division-by-zero errors on unusual networks. + * If consensus method 27 or later is used, the microdesc consensus + may include an "a" line for each router, listing an IPv6 OR port. + The signatures at the end of a consensus document are sorted in ascending order by identity digest. @@ -2793,6 +2798,7 @@ "24" -- No longer lists routers that are not Valid in the consensus. "25" -- Vote on recommended-protocols and required-protocols. "26" -- Initialize bandwidth weights to 1 to avoid division-by-zero. + "27" -- Adds support for "a" lines in microdescriptor consensues. Before generating a consensus, an authority must decide which consensus method to use. To do this, it looks for the highest version number @@ -3083,10 +3089,11 @@ [Any number] - IPv6 ORPorts are contained in microdescriptors and therefore omitted - in the microdescriptor consensus. + Identical to the "r" lines in section 3.4.1. - Not currently generated. + (Only included when the vote is generated with consensus-method 14 + or later, and the consensus is generated with consensus-method 27 or + later.) "p" ... NL

1 0

[torspec/master] Fix a minor size miscalculation in prop283
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit c0fbf526676ca86512d448e10901395e71ce2f78 Author: teor <teor2345(a)gmail.com> Date: Thu Oct 26 16:13:40 2017 +1100 Fix a minor size miscalculation in prop283 --- proposals/283-ipv6-in-micro-consensus.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/283-ipv6-in-micro-consensus.txt b/proposals/283-ipv6-in-micro-consensus.txt index 1334844..db57176 100644 --- a/proposals/283-ipv6-in-micro-consensus.txt +++ b/proposals/283-ipv6-in-micro-consensus.txt @@ -136,7 +136,7 @@ Target: 0.3.3.x 5. Data Size - This change removes 2-50 bytes from the microdescriptors of relays that + This change removes 7-50 bytes from the microdescriptors of relays that have an IPv6 ORPort, and adds them to reachable IPv6 relays' microdesc consensus entries.

1 0

[torspec/master] Merge remote-tracking branch 'teor/bug23826-23828-v2'
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit 48e41c559f5b5438838d15c4fd9a1b46c7296310 Merge: 0596c2c b523c5c Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Dec 4 11:48:43 2017 -0500 Merge remote-tracking branch 'teor/bug23826-23828-v2' dir-spec.txt | 38 ++++++---- proposals/283-ipv6-in-micro-consensus.txt | 111 ++++++++++++++++++------------ 2 files changed, 94 insertions(+), 55 deletions(-)

1 0

[torspec/master] Document current authority IPv6 reachability behaviour in dir-spec
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit 99e11bd5de4549ce335da2013645ebd8b39d2347 Author: teor <teor2345(a)gmail.com> Date: Tue Oct 17 22:47:26 2017 -0400 Document current authority IPv6 reachability behaviour in dir-spec This is the tor-spec part of #23870. --- dir-spec.txt | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index ffbe4d3..846f7a9 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2170,11 +2170,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 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. + "Running" if the router is currently usable over all its published + ORPorts. (Authorities ignore IPv6 ORPorts unless configured to + check IPv6 reachability.) 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 @@ -2379,12 +2379,15 @@ 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 on the ORPorts it considers - mandatory. Since 0.2.4.x, the mandatory ORPorts are: + it successfully within the last 45 minutes on all its published ORPorts. + Authorities check reachability on: * 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 + * AuthDirHasIPv6Connectivity 1 is set on the authority. + A minority of voting authorities that set AuthDirHasIPv6Connectivity will + drop unreachable IPv6 addresses from the full consensus. But they can not + drop IPv6 addresses from microdescriptors. "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

1 0

[tor/master] Add a consensus_method argument to routerstatus_format_entry()
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit b8d4588c90d399b4b4487dfbacfdbe6dd415aac4 Author: teor <teor2345(a)gmail.com> Date: Sun Oct 15 12:09:52 2017 -0400 Add a consensus_method argument to routerstatus_format_entry() And pass ROUTERSTATUS_FORMAT_NO_CONSENSUS_METHOD when it's not applicable. Preparation for #23826. --- src/or/dirserv.c | 11 +++++++++-- src/or/dirserv.h | 1 + src/or/dirvote.c | 7 +++++-- src/or/dirvote.h | 4 ++++ src/or/networkstatus.c | 4 +++- 5 files changed, 22 insertions(+), 5 deletions(-) diff --git a/src/or/dirserv.c b/src/or/dirserv.c index ddee92da5..42ffdfa0d 100644 --- a/src/or/dirserv.c +++ b/src/or/dirserv.c @@ -1897,21 +1897,28 @@ version_from_platform(const char *platform) /** Helper: write the router-status information in <b>rs</b> into a newly * allocated character buffer. Use the same format as in network-status * documents. If <b>version</b> is non-NULL, add a "v" line for the platform. + * + * consensus_method is the current consensus method when format is + * NS_V3_CONSENSUS or NS_V3_CONSENSUS_MICRODESC. It is ignored for other + * formats: pass ROUTERSTATUS_FORMAT_NO_CONSENSUS_METHOD. + * * Return 0 on success, -1 on failure. * * The format argument has one of the following values: * NS_V2 - Output an entry suitable for a V2 NS opinion document * NS_V3_CONSENSUS - Output the first portion of a V3 NS consensus entry + * for consensus_method. * NS_V3_CONSENSUS_MICRODESC - Output the first portion of a V3 microdesc - * consensus entry. + * consensus entry for consensus_method. * NS_V3_VOTE - Output a complete V3 NS vote. If <b>vrs</b> is present, * it contains additional information for the vote. - * NS_CONTROL_PORT - Output a NS document for the control port + * NS_CONTROL_PORT - Output a NS document for the control port. */ char * routerstatus_format_entry(const routerstatus_t *rs, const char *version, const char *protocols, routerstatus_format_type_t format, + int consensus_method, const vote_routerstatus_t *vrs) { char *summary; diff --git a/src/or/dirserv.h b/src/or/dirserv.h index 46967a6cb..9dc239f21 100644 --- a/src/or/dirserv.h +++ b/src/or/dirserv.h @@ -150,6 +150,7 @@ char *routerstatus_format_entry( const char *version, const char *protocols, routerstatus_format_type_t format, + int consensus_method, const vote_routerstatus_t *vrs); void dirserv_free_all(void); void cached_dir_decref(cached_dir_t *d); diff --git a/src/or/dirvote.c b/src/or/dirvote.c index ee6691cbb..12aa2363c 100644 --- a/src/or/dirvote.c +++ b/src/or/dirvote.c @@ -278,7 +278,9 @@ format_networkstatus_vote(crypto_pk_t *private_signing_key, vote_microdesc_hash_t *h; rsf = routerstatus_format_entry(&vrs->status, vrs->version, vrs->protocols, - NS_V3_VOTE, vrs); + NS_V3_VOTE, + ROUTERSTATUS_FORMAT_NO_CONSENSUS_METHOD, + vrs); if (rsf) smartlist_add(chunks, rsf); @@ -2100,7 +2102,8 @@ networkstatus_compute_consensus(smartlist_t *votes, char *buf; /* Okay!! Now we can write the descriptor... */ /* First line goes into "buf". */ - buf = routerstatus_format_entry(&rs_out, NULL, NULL, rs_format, NULL); + buf = routerstatus_format_entry(&rs_out, NULL, NULL, + rs_format, consensus_method, NULL); if (buf) smartlist_add(chunks, buf); } diff --git a/src/or/dirvote.h b/src/or/dirvote.h index fb3e60f00..ddf32277d 100644 --- a/src/or/dirvote.h +++ b/src/or/dirvote.h @@ -51,6 +51,10 @@ #define MIN_VOTE_INTERVAL_TESTING_INITIAL \ ((MIN_VOTE_SECONDS_TESTING)+(MIN_DIST_SECONDS_TESTING)+1) +/* A placeholder for routerstatus_format_entry() when the consensus method + * argument is not applicable. */ +#define ROUTERSTATUS_FORMAT_NO_CONSENSUS_METHOD 0 + /** The lowest consensus method that we currently support. */ #define MIN_SUPPORTED_CONSENSUS_METHOD 13 diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c index 93bb8643d..d31953d76 100644 --- a/src/or/networkstatus.c +++ b/src/or/networkstatus.c @@ -2193,7 +2193,9 @@ signed_descs_update_status_from_consensus_networkstatus(smartlist_t *descs) char * networkstatus_getinfo_helper_single(const routerstatus_t *rs) { - return routerstatus_format_entry(rs, NULL, NULL, NS_CONTROL_PORT, NULL); + return routerstatus_format_entry(rs, NULL, NULL, NS_CONTROL_PORT, + ROUTERSTATUS_FORMAT_NO_CONSENSUS_METHOD, + NULL); } /** Alloc and return a string describing routerstatuses for the most

1 0

[tor/master] Improve the comment on networkstatus_compute_consensus()
by nickm＠torproject.org 04 Dec '17

04 Dec '17

commit 305f9476713b8c2d098dc6ba8098a4a9f39a86ad Author: teor <teor2345(a)gmail.com> Date: Sun Oct 15 12:08:55 2017 -0400 Improve the comment on networkstatus_compute_consensus() --- src/or/dirvote.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/or/dirvote.c b/src/or/dirvote.c index ba0ab7a77..ee6691cbb 100644 --- a/src/or/dirvote.c +++ b/src/or/dirvote.c @@ -1315,8 +1315,9 @@ compute_nth_protocol_set(int n, int n_voters, const smartlist_t *votes) /** Given a list of vote networkstatus_t in <b>votes</b>, our public * authority <b>identity_key</b>, our private authority <b>signing_key</b>, * and the number of <b>total_authorities</b> that we believe exist in our - * voting quorum, generate the text of a new v3 consensus vote, and return the - * value in a newly allocated string. + * voting quorum, generate the text of a new v3 consensus or microdescriptor + * consensus (depending on <b>flavor</b>), and return the value in a newly + * allocated string. * * Note: this function DOES NOT check whether the votes are from * recognized authorities. (dirvote_add_vote does that.)

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits December 2017