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

[tor/master] Split the behavior of node_supports_ed25519_link_authentication().
by nickm＠torproject.org 09 Nov '17

09 Nov '17

commit 3124c921e7af15548b8b16d5f239bfdcd178b2ca Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Sep 11 10:00:11 2017 -0400 Split the behavior of node_supports_ed25519_link_authentication(). Before, this function meant "can we connect to this node and authenticate it using its ed25519 key?" Now it can additionally mean, "when somebody else connects to this node, do we expect that they can authenticate using the node's ed25519 key"? This change lets us future-proof our link authentication a bit. Closes ticket 20895. No backport needed, since ed25519 link authentication support has not been in any LTS release yet, and existing releases with it should be obsolete before any releases without support for linkauth=3 are released. --- changes/ticket20895 | 6 ++++++ src/or/circuitbuild.c | 4 ++-- src/or/connection_or.c | 2 +- src/or/dirserv.c | 4 ++-- src/or/hs_service.c | 2 +- src/or/nodelist.c | 20 +++++++++++++------- src/or/nodelist.h | 3 ++- src/or/or.h | 8 ++++++-- src/or/routerparse.c | 4 +++- 9 files changed, 36 insertions(+), 17 deletions(-) diff --git a/changes/ticket20895 b/changes/ticket20895 new file mode 100644 index 000000000..a1d820499 --- /dev/null +++ b/changes/ticket20895 @@ -0,0 +1,6 @@ + o Minor features (forward-compatibility): + - If a relay supports some link authentication protocol that we do not + recognize, then include that relay's ed25519 key when telling other + relays to extend to it. Previously, we treated future versions as if + they were too old to support ed25519 link authentication. + Closes ticket 20895. diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index 279308afc..45bf01954 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -1290,7 +1290,7 @@ circuit_extend(cell_t *cell, circuit_t *circ) const node_t *node = node_get_by_id((const char*)ec.node_id); const ed25519_public_key_t *node_ed_id = NULL; if (node && - node_supports_ed25519_link_authentication(node) && + node_supports_ed25519_link_authentication(node, 1) && (node_ed_id = node_get_ed25519_id(node))) { ed25519_pubkey_copy(&ec.ed_pubkey, node_ed_id); } @@ -2698,7 +2698,7 @@ extend_info_from_node(const node_t *node, int for_direct_connect) /* Don't send the ed25519 pubkey unless the target node actually supports * authenticating with it. */ - if (node_supports_ed25519_link_authentication(node)) { + if (node_supports_ed25519_link_authentication(node, 0)) { log_info(LD_CIRC, "Including Ed25519 ID for %s", node_describe(node)); ed_pubkey = node_get_ed25519_id(node); } else if (node_get_ed25519_id(node)) { diff --git a/src/or/connection_or.c b/src/or/connection_or.c index d890b58da..29c1166b3 100644 --- a/src/or/connection_or.c +++ b/src/or/connection_or.c @@ -886,7 +886,7 @@ connection_or_check_canonicity(or_connection_t *conn, int started_here) const node_t *r = node_get_by_id(id_digest); if (r && - node_supports_ed25519_link_authentication(r) && + node_supports_ed25519_link_authentication(r, 1) && ! node_ed25519_id_matches(r, ed_id)) { /* If this node is capable of proving an ed25519 ID, * we can't call this a canonical connection unless both IDs match. */ diff --git a/src/or/dirserv.c b/src/or/dirserv.c index 06ac15d58..75cd0879a 100644 --- a/src/or/dirserv.c +++ b/src/or/dirserv.c @@ -3284,7 +3284,7 @@ dirserv_orconn_tls_done(const tor_addr_t *addr, ri = node->ri; if (get_options()->AuthDirTestEd25519LinkKeys && - node_supports_ed25519_link_authentication(node) && + node_supports_ed25519_link_authentication(node, 1) && ri->cache_info.signing_key_cert) { /* We allow the node to have an ed25519 key if we haven't been told one in * the routerinfo, but if we *HAVE* been told one in the routerinfo, it @@ -3367,7 +3367,7 @@ dirserv_single_reachability_test(time_t now, routerinfo_t *router) tor_assert(node); if (options->AuthDirTestEd25519LinkKeys && - node_supports_ed25519_link_authentication(node)) { + node_supports_ed25519_link_authentication(node, 1)) { ed_id_key = &router->cache_info.signing_key_cert->signing_key; } else { ed_id_key = NULL; diff --git a/src/or/hs_service.c b/src/or/hs_service.c index 5759aa812..5ae7614e2 100644 --- a/src/or/hs_service.c +++ b/src/or/hs_service.c @@ -1494,7 +1494,7 @@ pick_intro_point(unsigned int direct_conn, smartlist_t *exclude_nodes) /* Let's do a basic sanity check here so that we don't end up advertising the * ed25519 identity key of relays that don't actually support the link * protocol */ - if (!node_supports_ed25519_link_authentication(node)) { + if (!node_supports_ed25519_link_authentication(node, 0)) { tor_assert_nonfatal(ed25519_public_key_is_zero(&info->ed_identity)); } diff --git a/src/or/nodelist.c b/src/or/nodelist.c index 00b8fb144..1f2d37f28 100644 --- a/src/or/nodelist.c +++ b/src/or/nodelist.c @@ -962,23 +962,29 @@ node_ed25519_id_matches(const node_t *node, const ed25519_public_key_t *id) } /** Return true iff <b>node</b> supports authenticating itself - * by ed25519 ID during the link handshake in a way that we can understand - * when we probe it. */ + * by ed25519 ID during the link handshake. If <b>compatible_with_us</b>, + * it needs to be using a link authentication method that we understand. + * If not, any plausible link authentication method will do. */ int -node_supports_ed25519_link_authentication(const node_t *node) +node_supports_ed25519_link_authentication(const node_t *node, + int compatible_with_us) { - /* XXXX Oh hm. What if some day in the future there are link handshake - * versions that aren't 3 but which are ed25519 */ if (! node_get_ed25519_id(node)) return 0; if (node->ri) { const char *protos = node->ri->protocol_list; if (protos == NULL) return 0; - return protocol_list_supports_protocol(protos, PRT_LINKAUTH, 3); + if (compatible_with_us) + return protocol_list_supports_protocol(protos, PRT_LINKAUTH, 3); + else + return protocol_list_supports_protocol_or_later(protos, PRT_LINKAUTH, 3); } if (node->rs) { - return node->rs->supports_ed25519_link_handshake; + if (compatible_with_us) + return node->rs->supports_ed25519_link_handshake_compat; + else + return node->rs->supports_ed25519_link_handshake_any; } tor_assert_nonfatal_unreached_once(); return 0; diff --git a/src/or/nodelist.h b/src/or/nodelist.h index 427e449ad..58743c5e7 100644 --- a/src/or/nodelist.h +++ b/src/or/nodelist.h @@ -65,7 +65,8 @@ const smartlist_t *node_get_declared_family(const node_t *node); const ed25519_public_key_t *node_get_ed25519_id(const node_t *node); int node_ed25519_id_matches(const node_t *node, const ed25519_public_key_t *id); -int node_supports_ed25519_link_authentication(const node_t *node); +int node_supports_ed25519_link_authentication(const node_t *node, + int compatible_with_us); int node_supports_v3_hsdir(const node_t *node); int node_supports_ed25519_hs_intro(const node_t *node); int node_supports_v3_rendezvous_point(const node_t *node); diff --git a/src/or/or.h b/src/or/or.h index 161d80ed9..8e1d15b8c 100644 --- a/src/or/or.h +++ b/src/or/or.h @@ -2316,8 +2316,12 @@ typedef struct routerstatus_t { unsigned int supports_extend2_cells:1; /** True iff this router has a protocol list that allows it to negotiate - * ed25519 identity keys on a link handshake. */ - unsigned int supports_ed25519_link_handshake:1; + * ed25519 identity keys on a link handshake with us. */ + unsigned int supports_ed25519_link_handshake_compat:1; + + /** True iff this router has a protocol list that allows it to negotiate + * ed25519 identity keys on a link handshake, at all. */ + unsigned int supports_ed25519_link_handshake_any:1; /** True iff this router has a protocol list that allows it to be an * introduction point supporting ed25519 authentication key which is part of diff --git a/src/or/routerparse.c b/src/or/routerparse.c index 08c3fc0a0..b26231db0 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -2701,8 +2701,10 @@ routerstatus_parse_entry_from_string(memarea_t *area, rs->protocols_known = 1; rs->supports_extend2_cells = protocol_list_supports_protocol(tok->args[0], PRT_RELAY, 2); - rs->supports_ed25519_link_handshake = + rs->supports_ed25519_link_handshake_compat = protocol_list_supports_protocol(tok->args[0], PRT_LINKAUTH, 3); + rs->supports_ed25519_link_handshake_any = + protocol_list_supports_protocol_or_later(tok->args[0], PRT_LINKAUTH, 3); rs->supports_ed25519_hs_intro = protocol_list_supports_protocol(tok->args[0], PRT_HSINTRO, 4); rs->supports_v3_hsdir =

1 0

[tor/master] Merge branch 'ticket20895'
by nickm＠torproject.org 09 Nov '17

09 Nov '17

commit 06260315645945ca9e08b5a19b67c8adad65a698 Merge: 59c1016ab 3124c921e Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 9 09:17:53 2017 -0500 Merge branch 'ticket20895' changes/ticket20895 | 6 ++++++ src/or/circuitbuild.c | 4 ++-- src/or/connection_or.c | 2 +- src/or/dirserv.c | 4 ++-- src/or/hs_service.c | 2 +- src/or/nodelist.c | 20 +++++++++++++------- src/or/nodelist.h | 3 ++- src/or/or.h | 8 ++++++-- src/or/protover.c | 36 ++++++++++++++++++++++++++++++++++++ src/or/protover.h | 3 +++ src/or/routerparse.c | 4 +++- src/test/test_protover.c | 30 ++++++++++++++++++++++++++++++ 12 files changed, 105 insertions(+), 17 deletions(-) diff --cc src/or/hs_service.c index a2082b391,5ae7614e2..8e2f52dcf --- a/src/or/hs_service.c +++ b/src/or/hs_service.c @@@ -1572,12 -1494,8 +1572,12 @@@ pick_intro_point(unsigned int direct_co /* Let's do a basic sanity check here so that we don't end up advertising the * ed25519 identity key of relays that don't actually support the link * protocol */ - if (!node_supports_ed25519_link_authentication(node)) { + if (!node_supports_ed25519_link_authentication(node, 0)) { tor_assert_nonfatal(ed25519_public_key_is_zero(&info->ed_identity)); + } else { + /* Make sure we *do* have an ed key if we support the link authentication. + * Sending an empty key would result in a failure to extend. */ + tor_assert_nonfatal(!ed25519_public_key_is_zero(&info->ed_identity)); } /* Create our objects and populate them with the node information. */ diff --cc src/test/test_protover.c index 9ae907183,874b31549..686536211 --- a/src/test/test_protover.c +++ b/src/test/test_protover.c @@@ -196,31 -183,34 +196,60 @@@ test_protover_all_supported(void *arg } static void +test_protover_list_supports_protocol_returns_true(void *arg) +{ + (void)arg; + + const char *protocols = "Link=1"; + int is_supported = protocol_list_supports_protocol(protocols, PRT_LINK, 1); + tt_int_op(is_supported, OP_EQ, 1); + + done: + ; +} + +static void +test_protover_list_supports_protocol_for_unsupported_returns_false(void *arg) +{ + (void)arg; + + const char *protocols = "Link=1"; + int is_supported = protocol_list_supports_protocol(protocols, PRT_LINK, 10); + tt_int_op(is_supported, OP_EQ, 0); + + done: + ; +} + ++static void + test_protover_supports_version(void *arg) + { + (void)arg; + + tt_assert(protocol_list_supports_protocol("Link=3-6", PRT_LINK, 3)); + tt_assert(protocol_list_supports_protocol("Link=3-6", PRT_LINK, 6)); + tt_assert(!protocol_list_supports_protocol("Link=3-6", PRT_LINK, 7)); + tt_assert(!protocol_list_supports_protocol("Link=3-6", PRT_LINKAUTH, 3)); + + tt_assert(!protocol_list_supports_protocol("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 2)); + tt_assert(protocol_list_supports_protocol("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 3)); + tt_assert(!protocol_list_supports_protocol("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 4)); + tt_assert(!protocol_list_supports_protocol_or_later("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 4)); + tt_assert(protocol_list_supports_protocol_or_later("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 3)); + tt_assert(protocol_list_supports_protocol_or_later("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 2)); + + tt_assert(!protocol_list_supports_protocol_or_later("Link=4-6 LinkAuth=3", + PRT_DESC, 2)); + done: + ; + } + #define PV_TEST(name, flags) \ { #name, test_protover_ ##name, (flags), NULL, NULL } @@@ -229,8 -219,7 +258,9 @@@ struct testcase_t protover_tests[] = PV_TEST(parse_fail, 0), PV_TEST(vote, 0), PV_TEST(all_supported, 0), + PV_TEST(list_supports_protocol_for_unsupported_returns_false, 0), + PV_TEST(list_supports_protocol_returns_true, 0), + PV_TEST(supports_version, 0), END_OF_TESTCASES };

1 0

[tor/master] Add a function to check for support for "protocol X or later"
by nickm＠torproject.org 09 Nov '17

09 Nov '17

commit 362bc880b1c4bbccba8698b872c16fc6a6da168e Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Sep 11 09:50:31 2017 -0400 Add a function to check for support for "protocol X or later" Also, add unit tests for this new function and for the regular "does this list include support for protocol X" code. --- src/or/protover.c | 36 ++++++++++++++++++++++++++++++++++++ src/or/protover.h | 3 +++ src/test/test_protover.c | 30 ++++++++++++++++++++++++++++++ 3 files changed, 69 insertions(+) diff --git a/src/or/protover.c b/src/or/protover.c index 1a3e69be1..5aaf4f4c3 100644 --- a/src/or/protover.c +++ b/src/or/protover.c @@ -280,6 +280,42 @@ protocol_list_supports_protocol(const char *list, protocol_type_t tp, return contains; } +/** + * Return true iff "list" encodes a protocol list that includes support for + * the indicated protocol and version, or some later version. + */ +int +protocol_list_supports_protocol_or_later(const char *list, + protocol_type_t tp, + uint32_t version) +{ + /* NOTE: This is a pretty inefficient implementation. If it ever shows + * up in profiles, we should memoize it. + */ + smartlist_t *protocols = parse_protocol_list(list); + if (!protocols) { + return 0; + } + const char *pr_name = protocol_type_to_str(tp); + + int contains = 0; + SMARTLIST_FOREACH_BEGIN(protocols, proto_entry_t *, proto) { + if (strcasecmp(proto->name, pr_name)) + continue; + SMARTLIST_FOREACH_BEGIN(proto->ranges, const proto_range_t *, range) { + if (range->high >= version) { + contains = 1; + goto found; + } + } SMARTLIST_FOREACH_END(range); + } SMARTLIST_FOREACH_END(proto); + + found: + SMARTLIST_FOREACH(protocols, proto_entry_t *, ent, proto_entry_free(ent)); + smartlist_free(protocols); + return contains; +} + /** Return the canonical string containing the list of protocols * that we support. */ const char * diff --git a/src/or/protover.h b/src/or/protover.h index ec8da1a0d..717645955 100644 --- a/src/or/protover.h +++ b/src/or/protover.h @@ -47,6 +47,9 @@ char *protover_compute_vote(const smartlist_t *list_of_proto_strings, const char *protover_compute_for_old_tor(const char *version); int protocol_list_supports_protocol(const char *list, protocol_type_t tp, uint32_t version); +int protocol_list_supports_protocol_or_later(const char *list, + protocol_type_t tp, + uint32_t version); void protover_free_all(void); diff --git a/src/test/test_protover.c b/src/test/test_protover.c index 6ce54890d..874b31549 100644 --- a/src/test/test_protover.c +++ b/src/test/test_protover.c @@ -182,6 +182,35 @@ test_protover_all_supported(void *arg) tor_free(msg); } +static void +test_protover_supports_version(void *arg) +{ + (void)arg; + + tt_assert(protocol_list_supports_protocol("Link=3-6", PRT_LINK, 3)); + tt_assert(protocol_list_supports_protocol("Link=3-6", PRT_LINK, 6)); + tt_assert(!protocol_list_supports_protocol("Link=3-6", PRT_LINK, 7)); + tt_assert(!protocol_list_supports_protocol("Link=3-6", PRT_LINKAUTH, 3)); + + tt_assert(!protocol_list_supports_protocol("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 2)); + tt_assert(protocol_list_supports_protocol("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 3)); + tt_assert(!protocol_list_supports_protocol("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 4)); + tt_assert(!protocol_list_supports_protocol_or_later("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 4)); + tt_assert(protocol_list_supports_protocol_or_later("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 3)); + tt_assert(protocol_list_supports_protocol_or_later("Link=4-6 LinkAuth=3", + PRT_LINKAUTH, 2)); + + tt_assert(!protocol_list_supports_protocol_or_later("Link=4-6 LinkAuth=3", + PRT_DESC, 2)); + done: + ; +} + #define PV_TEST(name, flags) \ { #name, test_protover_ ##name, (flags), NULL, NULL } @@ -190,6 +219,7 @@ struct testcase_t protover_tests[] = { PV_TEST(parse_fail, 0), PV_TEST(vote, 0), PV_TEST(all_supported, 0), + PV_TEST(supports_version, 0), END_OF_TESTCASES };

1 0

[tor/release-0.3.2] Merge branch 'bug23985_029' into maint-0.3.2
by nickm＠torproject.org 09 Nov '17

09 Nov '17

commit aa1d90b40c5f6e65b7b95cfb7e192e27e6530c52 Merge: 40c64f45f 0dc55fb24 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 9 08:15:46 2017 -0500 Merge branch 'bug23985_029' into maint-0.3.2 changes/bug23985 | 9 +++++++++ src/or/routerlist.c | 5 +++++ 2 files changed, 14 insertions(+)

1 0

[tor/master] Merge branch 'bug23985_029' into maint-0.3.2
by nickm＠torproject.org 09 Nov '17

09 Nov '17

commit aa1d90b40c5f6e65b7b95cfb7e192e27e6530c52 Merge: 40c64f45f 0dc55fb24 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 9 08:15:46 2017 -0500 Merge branch 'bug23985_029' into maint-0.3.2 changes/bug23985 | 9 +++++++++ src/or/routerlist.c | 5 +++++ 2 files changed, 14 insertions(+)

1 0

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

09 Nov '17

commit 59c1016aba63c62e658065475add3cf77f665afa Merge: ce3d5da0d aa1d90b40 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 9 08:17:46 2017 -0500 Merge branch 'maint-0.3.2' changes/bug23985 | 9 +++++++++ src/or/routerlist.c | 5 +++++ 2 files changed, 14 insertions(+)

1 0

[tor/master] Don't delay descriptor fetches when missing info needed for circuits
by nickm＠torproject.org 09 Nov '17

09 Nov '17

commit 0dc55fb24756c5ae80e71f6fce93d97d73efd2fc Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Nov 8 13:22:16 2017 -0500 Don't delay descriptor fetches when missing info needed for circuits When we have fewer than 15 descriptors to fetch, we will delay the fetch for a little while. That's fine, if we can go ahead and build circuits... but if not, it's a poor choice indeed. Fixes bug 23985; bugfix on 0.1.1.11-alpha. In 0.3.0.3-alpha, when we made primary guard descriptors necessary for circuit building, this situation got worse. --- changes/bug23985 | 9 +++++++++ src/or/routerlist.c | 5 +++++ 2 files changed, 14 insertions(+) diff --git a/changes/bug23985 b/changes/bug23985 new file mode 100644 index 000000000..9cb593796 --- /dev/null +++ b/changes/bug23985 @@ -0,0 +1,9 @@ + o Minor bugfixes (bootstrapping): + - Fetch descriptors aggressively whenever we lack enough + to build circuits, regardless of how many descriptors we are missing. + Previously, we would delay launching the fetch when we had fewer than + 15 missing descriptors, even if some of those descriptors were + blocking circuits from building. Fixes bug 23985; bugfix on + 0.1.1.11-alpha. The effects of this bug became worse in 0.3.0.3-alpha, + when we began treating missing descriptors from our primary guards + as a reason to delay circuits. diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 2365f28fd..1b7c81ad5 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -5035,6 +5035,11 @@ launch_descriptor_downloads(int purpose, log_debug(LD_DIR, "There are enough downloadable %ss to launch requests.", descname); + } else if (! router_have_minimum_dir_info()) { + log_debug(LD_DIR, + "We are only missing %d %ss, but we'll fetch anyway, since " + "we don't yet have enough directory info.", + n_downloadable, descname); } else { /* should delay */

1 0

[tor/release-0.3.2] Don't delay descriptor fetches when missing info needed for circuits
by nickm＠torproject.org 09 Nov '17

09 Nov '17

commit 0dc55fb24756c5ae80e71f6fce93d97d73efd2fc Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Nov 8 13:22:16 2017 -0500 Don't delay descriptor fetches when missing info needed for circuits When we have fewer than 15 descriptors to fetch, we will delay the fetch for a little while. That's fine, if we can go ahead and build circuits... but if not, it's a poor choice indeed. Fixes bug 23985; bugfix on 0.1.1.11-alpha. In 0.3.0.3-alpha, when we made primary guard descriptors necessary for circuit building, this situation got worse. --- changes/bug23985 | 9 +++++++++ src/or/routerlist.c | 5 +++++ 2 files changed, 14 insertions(+) diff --git a/changes/bug23985 b/changes/bug23985 new file mode 100644 index 000000000..9cb593796 --- /dev/null +++ b/changes/bug23985 @@ -0,0 +1,9 @@ + o Minor bugfixes (bootstrapping): + - Fetch descriptors aggressively whenever we lack enough + to build circuits, regardless of how many descriptors we are missing. + Previously, we would delay launching the fetch when we had fewer than + 15 missing descriptors, even if some of those descriptors were + blocking circuits from building. Fixes bug 23985; bugfix on + 0.1.1.11-alpha. The effects of this bug became worse in 0.3.0.3-alpha, + when we began treating missing descriptors from our primary guards + as a reason to delay circuits. diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 2365f28fd..1b7c81ad5 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -5035,6 +5035,11 @@ launch_descriptor_downloads(int purpose, log_debug(LD_DIR, "There are enough downloadable %ss to launch requests.", descname); + } else if (! router_have_minimum_dir_info()) { + log_debug(LD_DIR, + "We are only missing %d %ss, but we'll fetch anyway, since " + "we don't yet have enough directory info.", + n_downloadable, descname); } else { /* should delay */

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.2' into release-0.3.2
by nickm＠torproject.org 09 Nov '17

09 Nov '17

commit 6a8c1667df7114711a387c3f60989a02d594dcc0 Merge: 57deb20f3 aa1d90b40 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 9 08:17:46 2017 -0500 Merge branch 'maint-0.3.2' into release-0.3.2 changes/bug23985 | 9 +++++++++ src/or/routerlist.c | 5 +++++ 2 files changed, 14 insertions(+)

1 0

[tor/maint-0.3.2] Don't delay descriptor fetches when missing info needed for circuits
by nickm＠torproject.org 09 Nov '17

09 Nov '17

commit 0dc55fb24756c5ae80e71f6fce93d97d73efd2fc Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Nov 8 13:22:16 2017 -0500 Don't delay descriptor fetches when missing info needed for circuits When we have fewer than 15 descriptors to fetch, we will delay the fetch for a little while. That's fine, if we can go ahead and build circuits... but if not, it's a poor choice indeed. Fixes bug 23985; bugfix on 0.1.1.11-alpha. In 0.3.0.3-alpha, when we made primary guard descriptors necessary for circuit building, this situation got worse. --- changes/bug23985 | 9 +++++++++ src/or/routerlist.c | 5 +++++ 2 files changed, 14 insertions(+) diff --git a/changes/bug23985 b/changes/bug23985 new file mode 100644 index 000000000..9cb593796 --- /dev/null +++ b/changes/bug23985 @@ -0,0 +1,9 @@ + o Minor bugfixes (bootstrapping): + - Fetch descriptors aggressively whenever we lack enough + to build circuits, regardless of how many descriptors we are missing. + Previously, we would delay launching the fetch when we had fewer than + 15 missing descriptors, even if some of those descriptors were + blocking circuits from building. Fixes bug 23985; bugfix on + 0.1.1.11-alpha. The effects of this bug became worse in 0.3.0.3-alpha, + when we began treating missing descriptors from our primary guards + as a reason to delay circuits. diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 2365f28fd..1b7c81ad5 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -5035,6 +5035,11 @@ launch_descriptor_downloads(int purpose, log_debug(LD_DIR, "There are enough downloadable %ss to launch requests.", descname); + } else if (! router_have_minimum_dir_info()) { + log_debug(LD_DIR, + "We are only missing %d %ss, but we'll fetch anyway, since " + "we don't yet have enough directory info.", + n_downloadable, descname); } else { /* should delay */

1 0