- tor-commits - lists.torproject.org

[tor/release-0.2.1] Issues with router_get_by_nickname()
by arma＠torproject.org 23 Feb '11

23 Feb '11

commit e1d86d381714cb4e85f543fab0ca71f13e58767b Author: Robert Hogan <robert(a)roberthogan.net> Date: Thu Sep 30 21:41:20 2010 +0100 Issues with router_get_by_nickname() https://trac.torproject.org/projects/tor/ticket/1859 There are two problems in this bug: 1. When an OP makes a .exit request specifying itself as the exit, and the exit is not yet listed, Tor gets all the routerinfos needed for the circuit but discovers in circuit_is_acceptable() that its own routerinfo is not in the routerdigest list and cannot be used. Tor then gets locked in a cycle of repeating these two steps. When gathering the routerinfos for a circuit, specifically when the exit has been chosen by .exit notation, Tor needs to apply the same rules it uses later on when deciding if it can build a circuit with those routerinfos. 2. A different bug arises in the above situation when the Tor instance's routerinfo *is* listed in the routerlist, it shares its nickname with a number of other Tor nodes, and it does not have 'Named' rights to its nickname. So for example, if (i) there are five nodes named Bob in the network, (ii) I am running one of them but am flagged as 'Unnamed' because someone else claimed the 'Bob' nickname first, and (iii) I run my Tor as both client and exit the following can happen to me: - I go to www.evil.com - I click on a link www.evil.com.bob.exit - My request will exit through my own Tor node rather than the 'Named' node Bob or any of the others. - www.evil.com now knows I am actually browsing from the same computer that is running my 'Bob' node So to solve both issues we need to ensure: - When fulfilling a .exit request we only choose a routerinfo if it exists in the routerlist, even when that routerinfo is ours. - When getting a router by nickname we only return our own router information if it is not going to be used for building a circuit. We ensure this by removing the special treatment afforded our own router in router_get_by_nickname(). This means the function will only return the routerinfo of our own router if it is in the routerlist built from authority info and has a unique nickname or is bound to a non-unique nickname. There are some uses of router_get_by_nickname() where we are looking for the router by name because of a configuration directive, specifically local declaration of NodeFamilies and EntryNodes and other routers' declaration of MyFamily. In these cases it is not at first clear if we need to continue returning our own routerinfo even if our router is not listed and/or has a non-unique nickname with the Unnamed flag. The patch treats each of these cases as follows: Other Routers' Declaration of MyFamily This happens in routerlist_add_family(). If another router declares our router in its family and our router has the Unnamed flag or is not in the routerlist yet, should we take advantage of the fact that we know our own routerinfo to add us in anyway? This patch says 'no, treat our own router just like any other'. This is a safe choice because it ensures our client has the same view of the network as other clients. We also have no good way of knowing if our router is Named or not independently of the authorities, so we have to rely on them in this. Local declaration of NodeFamilies Again, we have no way of knowing if the declaration 'NodeFamilies Bob,Alice,Ringo' refers to our router Bob or the Named router Bob, so we have to defer to the authorities and treat our own router like any other. Local declaration of NodeFamilies Again, same as above. There's also no good reason we would want our client to choose it's own router as an entry guard if it does not meet the requirements expected of any other router on the network. In order to reduce the possibility of error, the patch also replaces two instances where we were using router_get_by_nickname() with calls to router_get_by_hexdigest() where the identity digest of the router is available. --- src/or/connection_edge.c | 2 +- src/or/rendclient.c | 2 +- src/or/routerlist.c | 3 --- 3 files changed, 2 insertions(+), 5 deletions(-) diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index ded02e9..eba83ba 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -571,7 +571,7 @@ circuit_discard_optional_exit_enclaves(extend_info_t *info) !edge_conn->chosen_exit_retries) continue; r1 = router_get_by_nickname(edge_conn->chosen_exit_name, 0); - r2 = router_get_by_nickname(info->nickname, 0); + r2 = router_get_by_hexdigest(info->identity_digest); if (!r1 || !r2 || r1 != r2) continue; tor_assert(edge_conn->socks_request); diff --git a/src/or/rendclient.c b/src/or/rendclient.c index 7023b7f..97fb6f0 100644 --- a/src/or/rendclient.c +++ b/src/or/rendclient.c @@ -810,7 +810,7 @@ rend_client_get_random_intro(const rend_data_t *rend_query) intro = smartlist_get(entry->parsed->intro_nodes, i); /* Do we need to look up the router or is the extend info complete? */ if (!intro->extend_info->onion_key) { - router = router_get_by_nickname(intro->extend_info->nickname, 0); + router = router_get_by_hexdigest(intro->extend_info->identity_digest); if (!router) { log_info(LD_REND, "Unknown router with nickname '%s'; trying another.", intro->extend_info->nickname); diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 2fc8073..9622406 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -1989,9 +1989,6 @@ router_get_by_nickname(const char *nickname, int warn_if_unnamed) return router_get_by_hexdigest(nickname); if (!strcasecmp(nickname, UNNAMED_ROUTER_NICKNAME)) return NULL; - if (server_mode(get_options()) && - !strcasecmp(nickname, get_options()->Nickname)) - return router_get_my_routerinfo(); maybedigest = (strlen(nickname) >= HEX_DIGEST_LEN) && (base16_decode(digest,DIGEST_LEN,nickname,HEX_DIGEST_LEN) == 0);

1 0

[tor/release-0.2.1] Issues with router_get_by_nickname()
by arma＠torproject.org 23 Feb '11

23 Feb '11

commit 7488fe5a224bf1c40d22769ff3986361d947d6f7 Author: Robert Hogan <robert(a)roberthogan.net> Date: Sun Oct 17 12:27:57 2010 +0100 Issues with router_get_by_nickname() https://trac.torproject.org/projects/tor/ticket/1859 Use router_get_by_digest() instead of router_get_by_hexdigest() in circuit_discard_optional_exit_enclaves() and rend_client_get_random_intro(), per Nick's comments. Using router_get_by_digest() in rend_client_get_random_intro() will break hidden services published by Tor versions pre 0.1.2.18 and 0.2.07-alpha as they only publish by nickname. This is acceptable however as these versions only publish to authority tor26 and don't work for versions in the 0.2.2.x series anyway. --- src/or/connection_edge.c | 2 +- src/or/rendclient.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index eba83ba..f72aa94 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -571,7 +571,7 @@ circuit_discard_optional_exit_enclaves(extend_info_t *info) !edge_conn->chosen_exit_retries) continue; r1 = router_get_by_nickname(edge_conn->chosen_exit_name, 0); - r2 = router_get_by_hexdigest(info->identity_digest); + r2 = router_get_by_digest(info->identity_digest); if (!r1 || !r2 || r1 != r2) continue; tor_assert(edge_conn->socks_request); diff --git a/src/or/rendclient.c b/src/or/rendclient.c index 97fb6f0..ca3f213 100644 --- a/src/or/rendclient.c +++ b/src/or/rendclient.c @@ -810,7 +810,7 @@ rend_client_get_random_intro(const rend_data_t *rend_query) intro = smartlist_get(entry->parsed->intro_nodes, i); /* Do we need to look up the router or is the extend info complete? */ if (!intro->extend_info->onion_key) { - router = router_get_by_hexdigest(intro->extend_info->identity_digest); + router = router_get_by_digest(intro->extend_info->identity_digest); if (!router) { log_info(LD_REND, "Unknown router with nickname '%s'; trying another.", intro->extend_info->nickname);

1 0

[tor/release-0.2.1] Simplest fix to bug2402: do not include SVN versions
by arma＠torproject.org 23 Feb '11

23 Feb '11

commit a1073ee956021ead19d30c2151510dbaced416a8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jan 25 14:08:13 2011 -0500 Simplest fix to bug2402: do not include SVN versions When we stopped using svn, 0.2.1.x lost the ability to notice its svn revision and report it in the version number. However, it kept looking at the micro-revision.i file... so if you switched to master, built tor, then switched to 0.2.1.x, you'd get a micro-revision.i file from master reported as an SVN tag. This patch takes out the "include the svn tag" logic entirely. Bugfix on 0.2.1.15-rc; fixes bug 2402. --- changes/bug2402 | 4 ++++ src/or/config.c | 11 +---------- 2 files changed, 5 insertions(+), 10 deletions(-) diff --git a/changes/bug2402 b/changes/bug2402 new file mode 100644 index 0000000..f16f677 --- /dev/null +++ b/changes/bug2402 @@ -0,0 +1,4 @@ + o Minor bugfixes (build) + - Do not include Git version tags as though they were SVN tags when + generating a tarball from inside a repository that has switched between + branches. Bugfix on 0.2.1.15-rc; fixes bug 2402. diff --git a/src/or/config.c b/src/or/config.c index f8cfd29..c5d6540 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -827,16 +827,7 @@ static char *_version = NULL; const char * get_version(void) { - if (_version == NULL) { - if (strlen(tor_svn_revision)) { - size_t len = strlen(VERSION)+strlen(tor_svn_revision)+8; - _version = tor_malloc(len); - tor_snprintf(_version, len, "%s (r%s)", VERSION, tor_svn_revision); - } else { - _version = tor_strdup(VERSION); - } - } - return _version; + return VERSION; } /** Release additional memory allocated in options

1 0

[tor/release-0.2.1] Fix a remaining bug in Robert's bug1859 fix.
by arma＠torproject.org 23 Feb '11

23 Feb '11

commit 2392290c1887b732fd2309e57ce04ab71b9b4e69 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Oct 21 11:08:15 2010 -0400 Fix a remaining bug in Robert's bug1859 fix. When intro->extend_info is created for an introduction point, it only starts out with a nickname, not necessarily an identity digest. Thus, doing router_get_by_digest isn't necessarily safe. --- src/or/rendclient.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/or/rendclient.c b/src/or/rendclient.c index ca3f213..1f253c1 100644 --- a/src/or/rendclient.c +++ b/src/or/rendclient.c @@ -810,7 +810,10 @@ rend_client_get_random_intro(const rend_data_t *rend_query) intro = smartlist_get(entry->parsed->intro_nodes, i); /* Do we need to look up the router or is the extend info complete? */ if (!intro->extend_info->onion_key) { - router = router_get_by_digest(intro->extend_info->identity_digest); + if (tor_digest_is_zero(intro->extend_info->identity_digest)) + router = router_get_by_hexdigest(intro->extend_info->nickname); + else + router = router_get_by_digest(intro->extend_info->identity_digest); if (!router) { log_info(LD_REND, "Unknown router with nickname '%s'; trying another.", intro->extend_info->nickname);

1 0

[tor/release-0.2.1] Issues with router_get_by_nickname() (3)
by arma＠torproject.org 23 Feb '11

23 Feb '11

commit 5cd7953a2112d6ae8702c741d73b8b6a2d0c5251 Author: Robert Hogan <robert(a)roberthogan.net> Date: Sun Oct 17 15:12:25 2010 +0100 Issues with router_get_by_nickname() (3) Add changes file --- changes/bug1859 | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/changes/bug1859 b/changes/bug1859 new file mode 100644 index 0000000..5b139f3 --- /dev/null +++ b/changes/bug1859 @@ -0,0 +1,9 @@ + o Minor bugfixes: + - Bring the logic that gathers routerinfos and assesses the + acceptability of circuits into line. This prevents a Tor OP from getting + locked in a cycle of choosing its local OR as an exit for a path (due to + a .exit request) and then rejecting the circuit because its OR is not + listed yet. Also prevent Tor clients from using an OR running in the same + instance as an exit (due to a .exit request) if the OR does not meet the + same requirements expected of an OR running elsewhere. + Fixes bug 1859; bugfix on 0.2.0-alpha.

1 0

r24258: {website} add the latest interview (website/trunk/press/en)
by Andrew Lewman 23 Feb '11

23 Feb '11

Author: phobos Date: 2011-02-23 00:21:44 +0000 (Wed, 23 Feb 2011) New Revision: 24258 Modified: website/trunk/press/en/inthemedia.wml Log: add the latest interview Modified: website/trunk/press/en/inthemedia.wml =================================================================== --- website/trunk/press/en/inthemedia.wml 2011-02-23 00:12:09 UTC (rev 24257) +++ website/trunk/press/en/inthemedia.wml 2011-02-23 00:21:44 UTC (rev 24258) @@ -159,6 +159,13 @@ <th>Topic</th> </tr> </thead> +<tr> +<td>2011 February 17</td> +<td>Walpole Times</td> +<td><a +href="http://www.wickedlocal.com/walpole/news/x95296113/Tor-Project-a-Walpole-bas…">Tor +Project, a Walpole-based company, helps Egyptians avoid Internet censorship during protests</a></td> +</tr> <tr style="background-color: #e5e5e5;"> <td>2011 February 01</td> <td>Discovery News</td>

1 0

r24257: {} add developer projects and direct user image for data to dat (projects/presentations/images)
by Andrew Lewman 23 Feb '11

23 Feb '11

Author: phobos Date: 2011-02-23 00:12:09 +0000 (Wed, 23 Feb 2011) New Revision: 24257 Added: projects/presentations/images/developer-projects.png projects/presentations/images/direct-users-2011-02-22-150-all-2009-09-01.png Log: add developer projects and direct user image for data to dateof code over time. Added: projects/presentations/images/developer-projects.png =================================================================== (Binary files differ) Property changes on: projects/presentations/images/developer-projects.png ___________________________________________________________________ Added: svn:mime-type + image/png Added: projects/presentations/images/direct-users-2011-02-22-150-all-2009-09-01.png =================================================================== (Binary files differ) Property changes on: projects/presentations/images/direct-users-2011-02-22-150-all-2009-09-01.png ___________________________________________________________________ Added: svn:mime-type + image/png

1 0

r24256: {projects} update vidalia network map shotanguage by quantity and lines (projects/presentations/images)
by Andrew Lewman 22 Feb '11

22 Feb '11

Author: phobos Date: 2011-02-22 23:58:14 +0000 (Tue, 22 Feb 2011) New Revision: 24256 Added: projects/presentations/images/hidden-federalist-zoom.png Modified: projects/presentations/images/hidden-federalist.png projects/presentations/images/vidalia-network-map.png Log: update vidalia network map shotanguage by quantity and lines of code over time. Added: projects/presentations/images/hidden-federalist-zoom.png =================================================================== (Binary files differ) Property changes on: projects/presentations/images/hidden-federalist-zoom.png ___________________________________________________________________ Added: svn:mime-type + image/png Modified: projects/presentations/images/hidden-federalist.png =================================================================== (Binary files differ) Modified: projects/presentations/images/vidalia-network-map.png =================================================================== (Binary files differ)

1 0

[tor/master] prevent same entry and exit for insane edge case
by nickm＠torproject.org 22 Feb '11

22 Feb '11

commit a2727f62494b8a56152214017ac8fb348dd064be Author: Roger Dingledine <arma(a)torproject.org> Date: Tue Feb 22 17:54:25 2011 -0500 prevent same entry and exit for insane edge case --- changes/bug2403 | 6 ++++++ src/or/circuitbuild.c | 3 ++- 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/changes/bug2403 b/changes/bug2403 new file mode 100644 index 0000000..3b29b37 --- /dev/null +++ b/changes/bug2403 @@ -0,0 +1,6 @@ + o Minor bugfixes: + - In the special case where you configure a public exit relay as your + bridge, Tor would be willing to use that exit relay as the last + hop in your circuit as well. Now we fail that circuit instead. + Bugfix on 0.2.0.12-alpha. Fixes bug 2403. Reported by "piebeer". + diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index 4f8f5fb..b3c9f0e 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -4063,7 +4063,6 @@ choose_random_entry(cpath_build_state_t *state) int preferred_min, consider_exit_family = 0; if (chosen_exit) { - smartlist_add(exit_family, chosen_exit); routerlist_add_family(exit_family, chosen_exit); consider_exit_family = 1; } @@ -4086,6 +4085,8 @@ choose_random_entry(cpath_build_state_t *state) r = entry_is_live(entry, need_uptime, need_capacity, 0, &msg); if (!r) continue; /* down, no point */ + if (r == chosen_exit) + continue; /* don't pick the same node for entry and exit */ if (consider_exit_family && smartlist_isin(exit_family, r)) continue; /* avoid relays that are family members of our exit */ if (options->EntryNodes &&

1 0

[tor/master] Merge remote branch 'arma/bug2403' into maint-0.2.2
by nickm＠torproject.org 22 Feb '11

22 Feb '11

commit 16b8b9b00f414343030c29990930c0e52a01fd84 Merge: 530e87c a2727f6 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Feb 22 18:38:03 2011 -0500 Merge remote branch 'arma/bug2403' into maint-0.2.2 changes/bug2403 | 6 ++++++ src/or/circuitbuild.c | 3 ++- 2 files changed, 8 insertions(+), 1 deletions(-)

1 0