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

[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

[tor/maint-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