February 2011 - tor-commits - lists.torproject.org

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

22 Feb '11

commit d120ee1c63ec52e23f24f3f4f9f80a9896381406 Merge: b99a8d5 19e5b4c Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Feb 22 01:03:06 2011 -0500 Merge remote branch 'origin/maint-0.2.2' changes/bug2572 | 5 +++++ src/or/router.c | 2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --combined src/or/router.c index 56f44cc,59276ba..ed998e4 --- a/src/or/router.c +++ b/src/or/router.c @@@ -7,7 -7,6 +7,7 @@@ #define ROUTER_PRIVATE #include "or.h" +#include "circuitbuild.h" #include "circuitlist.h" #include "circuituse.h" #include "config.h" @@@ -20,7 -19,6 +20,7 @@@ #include "hibernate.h" #include "main.h" #include "networkstatus.h" +#include "nodelist.h" #include "policies.h" #include "relay.h" #include "rephist.h" @@@ -152,8 -150,8 +152,8 @@@ assert_identity_keys_ok(void } else { /* assert that we have set the client and server keys to be unequal */ if (server_identitykey) - tor_assert(0!=crypto_pk_cmp_keys(client_identitykey, - server_identitykey)); + tor_assert(0!=crypto_pk_cmp_keys(client_identitykey, + server_identitykey)); } } @@@ -631,7 -629,7 +631,7 @@@ init_keys(void /* 4. Build our router descriptor. */ /* Must be called after keys are initialized. */ mydesc = router_get_my_descriptor(); - if (authdir_mode(options)) { + if (authdir_mode_handles_descs(options, ROUTER_PURPOSE_GENERAL)) { const char *m = NULL; routerinfo_t *ri; /* We need to add our own fingerprint so it gets recognized. */ @@@ -849,21 -847,18 +849,21 @@@ decide_to_advertise_dirport(or_options_ void consider_testing_reachability(int test_or, int test_dir) { - routerinfo_t *me = router_get_my_routerinfo(); + const routerinfo_t *me = router_get_my_routerinfo(); int orport_reachable = check_whether_orport_reachable(); tor_addr_t addr; if (!me) return; if (test_or && (!orport_reachable || !circuit_enough_testing_circs())) { + extend_info_t *ei; log_info(LD_CIRC, "Testing %s of my ORPort: %s:%d.", !orport_reachable ? "reachability" : "bandwidth", me->address, me->or_port); - circuit_launch_by_router(CIRCUIT_PURPOSE_TESTING, me, - CIRCLAUNCH_NEED_CAPACITY|CIRCLAUNCH_IS_INTERNAL); + ei = extend_info_from_router(me); + circuit_launch_by_extend_info(CIRCUIT_PURPOSE_TESTING, ei, + CIRCLAUNCH_NEED_CAPACITY|CIRCLAUNCH_IS_INTERNAL); + extend_info_free(ei); } tor_addr_from_ipv4h(&addr, me->addr); @@@ -887,7 -882,7 +887,7 @@@ voi router_orport_found_reachable(void) { if (!can_reach_or_port) { - routerinfo_t *me = router_get_my_routerinfo(); + const routerinfo_t *me = router_get_my_routerinfo(); log_notice(LD_OR,"Self-testing indicates your ORPort is reachable from " "the outside. Excellent.%s", get_options()->_PublishServerDescriptor != NO_AUTHORITY ? @@@ -910,7 -905,7 +910,7 @@@ voi router_dirport_found_reachable(void) { if (!can_reach_dir_port) { - routerinfo_t *me = router_get_my_routerinfo(); + const routerinfo_t *me = router_get_my_routerinfo(); log_notice(LD_DIRSERV,"Self-testing indicates your DirPort is reachable " "from the outside. Excellent."); can_reach_dir_port = 1; @@@ -1181,7 -1176,7 +1181,7 @@@ static int desc_needs_upload = 0 void router_upload_dir_desc_to_dirservers(int force) { - routerinfo_t *ri; + const routerinfo_t *ri; extrainfo_t *ei; char *msg; size_t desc_len, extra_len = 0, total_len; @@@ -1275,7 -1270,7 +1275,7 @@@ router_extrainfo_digest_is_me(const cha /** A wrapper around router_digest_is_me(). */ int -router_is_me(routerinfo_t *router) +router_is_me(const routerinfo_t *router) { return router_digest_is_me(router->cache_info.identity_digest); } @@@ -1294,7 -1289,7 +1294,7 @@@ router_fingerprint_is_me(const char *fp /** Return a routerinfo for this OR, rebuilding a fresh one if * necessary. Return NULL on error, or if called on an OP. */ -routerinfo_t * +const routerinfo_t * router_get_my_routerinfo(void) { if (!server_mode(get_options())) @@@ -1346,6 -1341,8 +1346,6 @@@ static int router_guess_address_from_di int router_pick_published_address(or_options_t *options, uint32_t *addr) { - char buf[INET_NTOA_BUF_LEN]; - struct in_addr a; if (resolve_my_address(LOG_INFO, options, addr, NULL) < 0) { log_info(LD_CONFIG, "Could not determine our address locally. " "Checking if directory headers provide any hints."); @@@ -1355,7 -1352,9 +1355,7 @@@ return -1; } } - a.s_addr = htonl(*addr); - tor_inet_ntoa(&a, buf, sizeof(buf)); - log_info(LD_CONFIG,"Success: chose address '%s'.", buf); + log_info(LD_CONFIG,"Success: chose address '%s'.", fmt_addr32(*addr)); return 0; } @@@ -1417,12 -1416,13 +1417,12 @@@ router_rebuild_descriptor(int force ri->policy_is_reject_star = policy_is_reject_star(ri->exit_policy); - if (desc_routerinfo) { /* inherit values */ - ri->is_valid = desc_routerinfo->is_valid; - ri->is_running = desc_routerinfo->is_running; - ri->is_named = desc_routerinfo->is_named; - } +#if 0 + /* XXXX NM NM I belive this is safe to remove */ if (authdir_mode(options)) ri->is_valid = ri->is_named = 1; /* believe in yourself */ +#endif + if (options->MyFamily) { smartlist_t *family; if (!warned_nonexistent_family) @@@ -1431,12 -1431,13 +1431,12 @@@ ri->declared_family = smartlist_create(); smartlist_split_string(family, options->MyFamily, ",", SPLIT_SKIP_SPACE|SPLIT_SKIP_SPACE|SPLIT_IGNORE_BLANK, 0); - SMARTLIST_FOREACH(family, char *, name, - { - routerinfo_t *member; + SMARTLIST_FOREACH_BEGIN(family, char *, name) { + const node_t *member; if (!strcasecmp(name, options->Nickname)) - member = ri; + goto skip; /* Don't list ourself, that's redundant */ else - member = router_get_by_nickname(name, 1); + member = node_get_by_nickname(name, 1); if (!member) { int is_legal = is_legal_nickname_or_hexdigest(name); if (!smartlist_string_isin(warned_nonexistent_family, name) && @@@ -1456,21 -1457,19 +1456,21 @@@ smartlist_add(ri->declared_family, name); name = NULL; } - } else if (router_is_me(member)) { + } else if (router_digest_is_me(member->identity)) { /* Don't list ourself in our own family; that's redundant */ + /* XXX shouldn't be possible */ } else { char *fp = tor_malloc(HEX_DIGEST_LEN+2); fp[0] = '$'; base16_encode(fp+1,HEX_DIGEST_LEN+1, - member->cache_info.identity_digest, DIGEST_LEN); + member->identity, DIGEST_LEN); smartlist_add(ri->declared_family, fp); if (smartlist_string_isin(warned_nonexistent_family, name)) smartlist_string_remove(warned_nonexistent_family, name); } + skip: tor_free(name); - }); + } SMARTLIST_FOREACH_END(name); /* remove duplicates from the list */ smartlist_sort_strings(ri->declared_family); @@@ -1531,6 -1530,8 +1531,6 @@@ strlen(ri->cache_info.signed_descriptor_body), ri->cache_info.signed_descriptor_digest); - routerinfo_set_country(ri); - if (ei) { tor_assert(! routerinfo_incompatible_with_extrainfo(ri, ei, NULL, NULL)); } @@@ -2023,12 -2024,6 +2023,12 @@@ extrainfo_dump_to_string(char **s_out, tor_free(bandwidth_usage); smartlist_add(chunks, pre); + if (geoip_is_loaded()) { + char *chunk=NULL; + tor_asprintf(&chunk, "geoip-db-digest %s\n", geoip_db_digest()); + smartlist_add(chunks, chunk); + } + if (options->ExtraInfoStatistics && write_stats_to_extrainfo) { log_info(LD_GENERAL, "Adding stats to extra-info descriptor."); if (options->DirReqStatistics && @@@ -2051,11 -2046,6 +2051,11 @@@ "exit-stats-end", now, &contents) > 0) { smartlist_add(chunks, contents); } + if (options->ConnDirectionStatistics && + load_stats_file("stats"PATH_SEPARATOR"conn-stats", + "conn-bi-direct", now, &contents) > 0) { + smartlist_add(chunks, contents); + } } if (should_record_bridge_info(options) && write_stats_to_extrainfo) { @@@ -2194,15 -2184,10 +2194,15 @@@ is_legal_hexdigest(const char *s void router_get_verbose_nickname(char *buf, const routerinfo_t *router) { + const char *good_digest = networkstatus_get_router_digest_by_nickname( + router->nickname); + int is_named = good_digest && !memcmp(good_digest, + router->cache_info.identity_digest, + DIGEST_LEN); buf[0] = '$'; base16_encode(buf+1, HEX_DIGEST_LEN+1, router->cache_info.identity_digest, DIGEST_LEN); - buf[1+HEX_DIGEST_LEN] = router->is_named ? '=' : '~'; + buf[1+HEX_DIGEST_LEN] = is_named ? '=' : '~'; strlcpy(buf+1+HEX_DIGEST_LEN+1, router->nickname, MAX_NICKNAME_LEN+1); }

1 0

[tor/master] Don't crash a bridge authority on SIGHUP if it's not in the consensus
by nickm＠torproject.org 22 Feb '11

22 Feb '11

commit 444a955e4a3877e9a7b3016deee9f1f4dfafdd93 Author: Robert Ransom <rransom.8774(a)gmail.com> Date: Wed Feb 16 04:12:37 2011 -0800 Don't crash a bridge authority on SIGHUP if it's not in the consensus Fixes bug 2572. --- changes/bug2572 | 5 +++++ src/or/router.c | 2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/changes/bug2572 b/changes/bug2572 new file mode 100644 index 0000000..a5cca28 --- /dev/null +++ b/changes/bug2572 @@ -0,0 +1,5 @@ + o Minor bugfixes: + - Don't crash a bridge authority on SIGHUP if it can't force itself + into its routerlist. Fixes bug 2572. + + diff --git a/src/or/router.c b/src/or/router.c index 26ac351..59276ba 100644 --- a/src/or/router.c +++ b/src/or/router.c @@ -629,7 +629,7 @@ init_keys(void) /* 4. Build our router descriptor. */ /* Must be called after keys are initialized. */ mydesc = router_get_my_descriptor(); - if (authdir_mode(options)) { + if (authdir_mode_handles_descs(options, ROUTER_PURPOSE_GENERAL)) { const char *m = NULL; routerinfo_t *ri; /* We need to add our own fingerprint so it gets recognized. */

1 0

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

22 Feb '11

commit 19e5b4c2f269c8842646213c8d78562553a7bfc8 Merge: d673479 444a955 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Feb 22 01:02:35 2011 -0500 Merge remote branch 'rransom/bug2572' into maint-0.2.2 changes/bug2572 | 5 +++++ src/or/router.c | 2 +- 2 files changed, 6 insertions(+), 1 deletions(-)

1 0

[tor/maint-0.2.2] Don't crash a bridge authority on SIGHUP if it's not in the consensus
by nickm＠torproject.org 22 Feb '11

22 Feb '11

commit 444a955e4a3877e9a7b3016deee9f1f4dfafdd93 Author: Robert Ransom <rransom.8774(a)gmail.com> Date: Wed Feb 16 04:12:37 2011 -0800 Don't crash a bridge authority on SIGHUP if it's not in the consensus Fixes bug 2572. --- changes/bug2572 | 5 +++++ src/or/router.c | 2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/changes/bug2572 b/changes/bug2572 new file mode 100644 index 0000000..a5cca28 --- /dev/null +++ b/changes/bug2572 @@ -0,0 +1,5 @@ + o Minor bugfixes: + - Don't crash a bridge authority on SIGHUP if it can't force itself + into its routerlist. Fixes bug 2572. + + diff --git a/src/or/router.c b/src/or/router.c index 26ac351..59276ba 100644 --- a/src/or/router.c +++ b/src/or/router.c @@ -629,7 +629,7 @@ init_keys(void) /* 4. Build our router descriptor. */ /* Must be called after keys are initialized. */ mydesc = router_get_my_descriptor(); - if (authdir_mode(options)) { + if (authdir_mode_handles_descs(options, ROUTER_PURPOSE_GENERAL)) { const char *m = NULL; routerinfo_t *ri; /* We need to add our own fingerprint so it gets recognized. */

1 0

r24253: {website} Clean up TAILS project descriptions (website/trunk/getinvolved/en)
by Robert Ransom 22 Feb '11

22 Feb '11

Author: rransom Date: 2011-02-22 03:30:33 +0000 (Tue, 22 Feb 2011) New Revision: 24253 Modified: website/trunk/getinvolved/en/volunteer.wml Log: Clean up TAILS project descriptions Modified: website/trunk/getinvolved/en/volunteer.wml =================================================================== --- website/trunk/getinvolved/en/volunteer.wml 2011-02-22 02:29:09 UTC (rev 24252) +++ website/trunk/getinvolved/en/volunteer.wml 2011-02-22 03:30:33 UTC (rev 24253) @@ -990,18 +990,18 @@ Skill Level: Low to Medium Likely Mentors: intrigeri, anonym - Tor helps greatly publishing files anonymously. However, much personal - information can be enclosed *inside* such published files meta-data: GPS - coordinates, authors name and so on. Anyone who wants to anonymously + Tor helps greatly in publishing files anonymously. However, much personal + information can be enclosed *inside* such published files' meta-data: GPS + coordinates, author's name and so on. Anyone who wants to anonymously publish a file can thus far too easily de-anonymize herself. - A set of tools allowing to easily inspect and cleanup meta-data in files + A set of tools allowing users to easily inspect and clean up meta-data in files would benefit Tor users, and would e.g. be shipped in TAILS. A graphical user interface is a must, but library and command-line interfaces are most welcome so that future work can add support for - published files cleaning to various publishing tools, such as Desktop + cleaning published files to various publishing tools, such as desktop social networking clients and Web content management systems. - This project mostly consists in writing glue between the many existing - tools and libraries that provide read/write access to files meta-data. An + This project mostly consists of writing glue between the many existing + tools and libraries that provide read/write access to files' meta-data. An extensible program design would probably be the best bet, so that support for other kinds of files can easily be added later. The meta-data cleaning toolkit would run at least on GNU/Linux; @@ -1021,15 +1021,15 @@ Likely Mentors: intrigeri, anonym Data persistence is a somewhat tricky topic in a Live system context, - especially one explicitly designed to avoid leaving any trace of its use - such as TAILS. - Some real-life usecases however require to setup some kind of data + especially one such as TAILS, which is explicitly designed to avoid + leaving any trace of its use. + Some real-life use cases, however, require some kind of data persistence. To start with, TAILS should (carefully) support persistence of application-specific configurations (e.g. GnuPG keyring) and of a user arbitrary data store. Note that persistence in TAILS will always be opt-in and require encrypted storage. - The backend part work consists in improving Debian Live existing - persistence features to make them suit the specific TAILS context. A trust + The backend work consists of improving Debian Live's existing + persistence features to make them suit the specific context of TAILS. A trust relationship is already established with upstream who is happy to merge our changes. The codebase is not that small and much refactoring is needed, so this really is a programming project rather than a fire'n'forget shell @@ -1037,7 +1037,7 @@ Anyone undertaking this project must be familiar with GNU/Linux, and preferably with Debian. Being able to (quickly learn to) write clean and safe programs in shell is also needed. - For more information see <a href="https://amnesia.boum.org/todo/persistence/">https://amnesia.boum.org/todo/persistence/</a> + For more information, see <a href="https://amnesia.boum.org/todo/persistence/">https://amnesia.boum.org/todo/persistence/</a>. <a id="torsocksForOSX"></a> <li>

1 0

r24252: {website} Tails project ideas provided by intrigeri. (website/trunk/getinvolved/en)
by Damian Johnson 22 Feb '11

22 Feb '11

Author: atagar Date: 2011-02-22 02:29:09 +0000 (Tue, 22 Feb 2011) New Revision: 24252 Modified: website/trunk/getinvolved/en/volunteer.wml Log: Tails project ideas provided by intrigeri. Modified: website/trunk/getinvolved/en/volunteer.wml =================================================================== --- website/trunk/getinvolved/en/volunteer.wml 2011-02-21 22:41:21 UTC (rev 24251) +++ website/trunk/getinvolved/en/volunteer.wml 2011-02-22 02:29:09 UTC (rev 24252) @@ -317,6 +317,16 @@ and still under very active development. + + Project Ideas: + <a href="#tailsStartMenu">Custom GDM3 startup menu, aka. + tails-greeter</a> + <a href="#tailsMetadataAnonymizing">Meta-data anonymizing toolkit for + file publication</a> + <a href="#tailsDebianLive">Improve Debian Live support for + persistence</a> + + <a id="project-torsocks"></a> <h3><a href="http://code.google.com/p/torsocks/">Torsocks</a> (<a href="https://gitweb.torproject.org/torsocks.git">code</a>, <a @@ -604,6 +614,35 @@ TBB, please contact Erinn. </li> + <a id="tailsStartMenu"></a> + <li> + Custom GDM3 startup menu, aka. tails-greeter + + Priority: High + + Effort Level: Medium + + Skill Level: Medium to High + + Likely Mentors: intrigeri, anonym + Several major upcoming TAILS features need to gather user input at + startup time: bridges support, persistence, MAC address anonymization, + etc. + Existing boot menus lack the graphical widgets and generally + user-friendliness needed. Hence it was decided to implement TAILS startup + menu in GDM3: GDM3's default login/password prompt needs to be replaced + with a custom GTK+ application hereby named tails-greeter that allows the + user to provide any input necessary. + Anyone undertaking this project should be familiar with GNU/Linux and + application development; no other skill is required, apart of the ability + to quickly find practical answers in APIs and documentation for many + technologies she knows nothing about: this challenging coding project will + indeed involve getting familiar with some modern GNU/Linux Desktop + technologies such as D-Bus, GNOME and GConf. Python/GTK+ is probably the + best suited language for the task. + For more information see <a href="https://amnesia.boum.org/todo/boot_menu/">https://amnesia.boum.org/todo/boot_menu/</a> + </li> +  + + <a id="tailsMetadataAnonymizing"></a> + <li> + Meta-data anonymizing toolkit for file publication + + Priority: Medium + + Effort Level: Low to Medium + + Skill Level: Low to Medium + + Likely Mentors: intrigeri, anonym + Tor helps greatly publishing files anonymously. However, much personal + information can be enclosed *inside* such published files meta-data: GPS + coordinates, authors name and so on. Anyone who wants to anonymously + publish a file can thus far too easily de-anonymize herself. + A set of tools allowing to easily inspect and cleanup meta-data in files + would benefit Tor users, and would e.g. be shipped in TAILS. + A graphical user interface is a must, but library and command-line + interfaces are most welcome so that future work can add support for + published files cleaning to various publishing tools, such as Desktop + social networking clients and Web content management systems. + This project mostly consists in writing glue between the many existing + tools and libraries that provide read/write access to files meta-data. An + extensible program design would probably be the best bet, so that support + for other kinds of files can easily be added later. + The meta-data cleaning toolkit would run at least on GNU/Linux; + additional Windows and/or Mac OS X support would be welcome. The tools used + would be up to the students. The detailed specification is ready and will + be published soon. + + <a id="tailsDebianLive"></a> + <li> + Improve Debian Live support for persistence + + Priority: Medium + + Effort Level: Medium + + Skill Level: Low to Medium + + Likely Mentors: intrigeri, anonym + Data persistence is a somewhat tricky topic in a Live system context, + especially one explicitly designed to avoid leaving any trace of its use + such as TAILS. + Some real-life usecases however require to setup some kind of data + persistence. To start with, TAILS should (carefully) support persistence of + application-specific configurations (e.g. GnuPG keyring) and of a user + arbitrary data store. Note that persistence in TAILS will always be opt-in + and require encrypted storage. + The backend part work consists in improving Debian Live existing + persistence features to make them suit the specific TAILS context. A trust + relationship is already established with upstream who is happy to merge our + changes. The codebase is not that small and much refactoring is needed, so + this really is a programming project rather than a fire'n'forget shell + script hack contest. + Anyone undertaking this project must be familiar with GNU/Linux, and + preferably with Debian. Being able to (quickly learn to) write clean and + safe programs in shell is also needed. + For more information see <a href="https://amnesia.boum.org/todo/persistence/">https://amnesia.boum.org/todo/persistence/</a> + <a id="torsocksForOSX"></a> <li> Make torsocks/dsocks work on OS X

1 0

[torspec/master] Update dir-spec with note about consensus method 11
by nickm＠torproject.org 21 Feb '11

21 Feb '11

commit e23476c813c84763428b39e2b567a5852b5c2aab Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Mon Feb 21 23:22:50 2011 +0100 Update dir-spec with note about consensus method 11 --- dir-spec.txt | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 49b64e8..63e0be9 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1662,6 +1662,8 @@ "8" -- Provides microdescriptor summaries "9" -- Provides weights for selecting flagged routers in paths "10" -- Fixes edge case bugs in router flag selection weights + "11" -- Don't consider BadExits when calculating bandwidth weights + 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

r24251: {website} namechange per request from thomas (website/trunk/about/en)
by Runa Sandvik 21 Feb '11

21 Feb '11

Author: runa Date: 2011-02-21 22:41:21 +0000 (Mon, 21 Feb 2011) New Revision: 24251 Modified: website/trunk/about/en/corepeople.wml Log: namechange per request from thomas Modified: website/trunk/about/en/corepeople.wml =================================================================== --- website/trunk/about/en/corepeople.wml 2011-02-21 22:10:53 UTC (rev 24250) +++ website/trunk/about/en/corepeople.wml 2011-02-21 22:41:21 UTC (rev 24251) @@ -83,7 +83,7 @@ the 2009 Google Summer of Code on expanding our secure updater to include BitTorrent support. Manages our git repository, reviews code patches, and generally helps out a lot.</dd> - <dt>Tom Heydt-Benjamin, Researcher</dt> + <dt>Thomas S. Benjamin, Researcher</dt> <dd>Anonymous communications and bridge distribution researcher. His other work can be found on his <a href="http://cryptocracy.net/">personal website</a></dd>

1 0

r24250: {website} Fix links that broke due to splitting the spec in its own re (in website/trunk: about/en docs/en getinvolved/en include)
by Sebastian Hahn 21 Feb '11

21 Feb '11

Author: sebastian Date: 2011-02-21 22:10:53 +0000 (Mon, 21 Feb 2011) New Revision: 24250 Modified: website/trunk/about/en/contributors.wml website/trunk/about/en/corepeople.wml website/trunk/docs/en/bridges.wml website/trunk/docs/en/documentation.wml website/trunk/docs/en/faq.wml website/trunk/getinvolved/en/volunteer.wml website/trunk/include/links.wmi Log: Fix links that broke due to splitting the spec in its own repo Modified: website/trunk/about/en/contributors.wml =================================================================== --- website/trunk/about/en/contributors.wml 2011-02-21 06:00:17 UTC (rev 24249) +++ website/trunk/about/en/contributors.wml 2011-02-21 22:10:53 UTC (rev 24250) @@ -24,7 +24,7 @@ Improving Tor Path Selection (<a href="https://svn.torproject.org/cgi-bin/viewvc.cgi/torflow/branches/gsoc2008/">svn</a>) and <a -href="<gitblob>doc/spec/proposals/151-path-selection-improvements.txt">proposal +href="<specblob>proposals/151-path-selection-improvements.txt">proposal 151</a> as part of Google Summer of Code 2008.</dd> <dt>Bram Cohen</dt><dd>Helped design our congestion control mechanisms, in Tor's early days.</dd> Modified: website/trunk/about/en/corepeople.wml =================================================================== --- website/trunk/about/en/corepeople.wml 2011-02-21 06:00:17 UTC (rev 24249) +++ website/trunk/about/en/corepeople.wml 2011-02-21 22:10:53 UTC (rev 24250) @@ -105,7 +105,7 @@ press, and general support.</dd> <dt>Dr. Karsten Loesing, Researcher and Developer</dt> <dd>Worked during the 2007 Google Summer of Code on <a - href="<gitblob>doc/spec/proposals/114-distributed-storage.txt">distributing + href="<specblob>proposals/114-distributed-storage.txt">distributing and securing the publishing and fetching of hidden service descriptors</a>. Currently the primary researcher for our National Science Foundation grant Modified: website/trunk/docs/en/bridges.wml =================================================================== --- website/trunk/docs/en/bridges.wml 2011-02-21 06:00:17 UTC (rev 24249) +++ website/trunk/docs/en/bridges.wml 2011-02-21 22:10:53 UTC (rev 24250) @@ -192,7 +192,7 @@ If you would like to learn more about our bridge design from a technical standpoint, please read the <a - href="<gitblob>doc/spec/bridges-spec.txt">Tor bridges + href="<specblob>bridges-spec.txt">Tor bridges specification</a>. If you're interested in running an unpublished bridge or other non-standard uses, please do read the specification. Modified: website/trunk/docs/en/documentation.wml =================================================================== --- website/trunk/docs/en/documentation.wml 2011-02-21 06:00:17 UTC (rev 24249) +++ website/trunk/docs/en/documentation.wml 2011-02-21 22:10:53 UTC (rev 24250) @@ -137,9 +137,9 @@ <li> Learn about the <a - href="<gitblob>doc/spec/proposals/001-process.txt">Tor + href="<specblob>proposals/001-process.txt">Tor proposal process for changing our design</a>, and look over the <a - href="<gittree>doc/spec/proposals">existing proposals</a>. + href="<spectree>proposals">existing proposals</a>. </li> <li> @@ -210,25 +210,25 @@ <li>The specifications aim to give developers enough information to build a compatible version of Tor: <ul> - <li><a href="<gitblob>doc/spec/tor-spec.txt">Main Tor specification</a></li> - <li><a href="<gitblob>doc/spec/dir-spec.txt">Tor + <li><a href="<specblob>tor-spec.txt">Main Tor specification</a></li> + <li><a href="<specblob>dir-spec.txt">Tor version 3 directory server specification</a> (and older <a - href="<gitblob>doc/spec/dir-spec-v1.txt">version 1</a> and <a - href="<gitblob>doc/spec/dir-spec-v2.txt">version 2</a> directory + href="<specblob>dir-spec-v1.txt">version 1</a> and <a + href="<specblob>dir-spec-v2.txt">version 2</a> directory specifications)</li> - <li><a href="<gitblob>doc/spec/control-spec.txt">Tor control protocol + <li><a href="<specblob>control-spec.txt">Tor control protocol specification</a></li> - <li><a href="<gitblob>doc/spec/rend-spec.txt">Tor rendezvous + <li><a href="<specblob>rend-spec.txt">Tor rendezvous specification</a></li> - <li><a href="<gitblob>doc/spec/path-spec.txt">Tor path selection + <li><a href="<specblob>path-spec.txt">Tor path selection specification</a></li> - <li><a href="<gitblob>doc/spec/address-spec.txt">Special hostnames in + <li><a href="<specblob>address-spec.txt">Special hostnames in Tor</a></li> - <li><a href="<gitblob>doc/spec/socks-extensions.txt">Tor's SOCKS support + <li><a href="<specblob>socks-extensions.txt">Tor's SOCKS support and extensions</a></li> - <li><a href="<gitblob>doc/spec/version-spec.txt">How Tor version numbers + <li><a href="<specblob>version-spec.txt">How Tor version numbers work</a></li> - <li><a href="<gittree>doc/spec/proposals">In-progress drafts of + <li><a href="<spectree>proposals">In-progress drafts of new specifications and proposed changes</a></li> </ul></li> Modified: website/trunk/docs/en/faq.wml =================================================================== --- website/trunk/docs/en/faq.wml 2011-02-21 06:00:17 UTC (rev 24249) +++ website/trunk/docs/en/faq.wml 2011-02-21 22:10:53 UTC (rev 24250) @@ -1461,7 +1461,7 @@ have the right keys for them? Each relay has a long-term public signing key called the "identity key". Each directory authority additionally has a "directory signing key". The directory authorities <a - href="<gitblob>doc/spec/dir-spec.txt">provide a signed list</a> + href="<specblob>dir-spec.txt">provide a signed list</a> of all the known relays, and in that list are a set of certificates from each relay (self-signed by their identity key) specifying their keys, locations, exit policies, and so on. So unless the adversary can control Modified: website/trunk/getinvolved/en/volunteer.wml =================================================================== --- website/trunk/getinvolved/en/volunteer.wml 2011-02-21 06:00:17 UTC (rev 24249) +++ website/trunk/getinvolved/en/volunteer.wml 2011-02-21 22:10:53 UTC (rev 24250) @@ -665,7 +665,7 @@ If you want to get more into the guts of Tor itself (C), a more minor problem we should address is that current Tors can only listen on a single address/port combination at a time. There's - <a href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">a + <a href="<specblob>proposals/118-multiple-orports.txt">a proposal to address this limitation</a> and allow clients to connect to any given Tor on multiple addresses and ports, but it needs more work. @@ -1096,7 +1096,7 @@ Currently, on Debian and Ubuntu, there is a configuration mechanism which allows Vidalia to override Tor's ability to start on boot (by sourcing <code>/etc/default/tor.vidalia</code> which sets <code>RUN_DAEMON=no</code> at the user's - request), but full implementation of <a href="<gitblob>doc/spec/control-spec.txt">ControlPort</a> + request), but full implementation of <a href="<specblob>control-spec.txt">ControlPort</a> communication is still required. @@ -1150,7 +1150,7 @@ href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor development roadmap</a> for more ideas, or just try out Tor, Vidalia, and Torbutton, and find out what you think needs fixing. - Some of the <a href="<gittree>doc/spec/proposals">current proposals</a> + Some of the <a href="<spectree>proposals">current proposals</a> might also be short on developers. </li> @@ -1206,7 +1206,7 @@ href="<page docs/faq>#TransportIPnotTCP">list of reasons why we haven't shifted to UDP transport</a>, but it would be great to see that list get shorter. We also have a proposed <a - href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">specification + href="<specblob>proposals/100-tor-spec-udp.txt">specification for Tor and UDP</a> — please let us know what's wrong with it.</li> @@ -1230,7 +1230,7 @@ <li> Another anti-censorship project is to try to make Tor more scanning-resistant. Right now, an adversary can identify <a - href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a> + href="<specblob>proposals/125-bridges.txt">Tor bridges</a> just by trying to connect to them, following the Tor protocol, and seeing if they respond. To solve this, bridges could <a href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like Modified: website/trunk/include/links.wmi =================================================================== --- website/trunk/include/links.wmi 2011-02-21 06:00:17 UTC (rev 24249) +++ website/trunk/include/links.wmi 2011-02-21 22:10:53 UTC (rev 24250) @@ -10,7 +10,10 @@ <define-tag wikifaq whitespace=delete>https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ</define-tag> <define-tag blog whitespace=delete>https://blog.torproject.org/blog/</define-tag> <define-tag tbbrepo whitespace=delete>https://gitweb.torproject.org/torbrowser.git/blob_plain/HEAD:</define-tag> +<define-tag specblob whitespace=delete>https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=</define-tag> +<define-tag spectree whitespace=delete>https://gitweb.torproject.org/torspec.git?a=tree;hb=HEAD;f=</define-tag> + # Xinclude "locallinks.wmi" # Xinclude "langlocallinks.$(LANG).wmi"

1 0

[tor/master] Merge remote branch 'origin/maint-0.2.2'
by nickm＠torproject.org 21 Feb '11

21 Feb '11

commit b99a8d54271dfd26c5c3a2d3086226974b32373e Merge: 90f9caf d673479 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Feb 21 16:10:31 2011 -0500 Merge remote branch 'origin/maint-0.2.2' Conflicts: doc/spec/Makefile.am doc/spec/control-spec.txt doc/spec/dir-spec.txt doc/spec/proposals/000-index.txt doc/spec/proposals/001-process.txt doc/spec/proposals/ideas/xxx-encrypted-services.txt doc/Makefile.am | 7 +- doc/spec/Makefile.am | 12 - doc/spec/README | 10 + doc/spec/address-spec.txt | 58 - doc/spec/bridges-spec.txt | 249 -- doc/spec/control-spec-v0.txt | 498 ---- doc/spec/control-spec.txt | 2001 ---------------- doc/spec/dir-spec-v1.txt | 314 --- doc/spec/dir-spec-v2.txt | 896 ------- doc/spec/dir-spec.txt | 2440 -------------------- doc/spec/path-spec.txt | 657 ------ doc/spec/proposals/000-index.txt | 196 -- doc/spec/proposals/001-process.txt | 184 -- doc/spec/proposals/098-todo.txt | 107 - doc/spec/proposals/099-misc.txt | 28 - doc/spec/proposals/100-tor-spec-udp.txt | 422 ---- doc/spec/proposals/101-dir-voting.txt | 283 --- doc/spec/proposals/102-drop-opt.txt | 38 - doc/spec/proposals/103-multilevel-keys.txt | 204 -- doc/spec/proposals/104-short-descriptors.txt | 181 -- doc/spec/proposals/105-handshake-revision.txt | 323 --- doc/spec/proposals/106-less-tls-constraint.txt | 111 - doc/spec/proposals/107-uptime-sanity-checking.txt | 54 - doc/spec/proposals/108-mtbf-based-stability.txt | 88 - doc/spec/proposals/109-no-sharing-ips.txt | 90 - doc/spec/proposals/110-avoid-infinite-circuits.txt | 120 - doc/spec/proposals/111-local-traffic-priority.txt | 151 -- .../proposals/112-bring-back-pathlencoinweight.txt | 163 -- .../proposals/113-fast-authority-interface.txt | 85 - doc/spec/proposals/114-distributed-storage.txt | 439 ---- doc/spec/proposals/115-two-hop-paths.txt | 385 --- .../proposals/116-two-hop-paths-from-guard.txt | 118 - doc/spec/proposals/117-ipv6-exits.txt | 410 ---- doc/spec/proposals/118-multiple-orports.txt | 84 - doc/spec/proposals/119-controlport-auth.txt | 140 -- doc/spec/proposals/120-shutdown-descriptors.txt | 83 - .../121-hidden-service-authentication.txt | 776 ------- doc/spec/proposals/122-unnamed-flag.txt | 136 -- doc/spec/proposals/123-autonaming.txt | 54 - doc/spec/proposals/124-tls-certificates.txt | 313 --- doc/spec/proposals/125-bridges.txt | 291 --- doc/spec/proposals/126-geoip-reporting.txt | 410 ---- .../proposals/127-dirport-mirrors-downloads.txt | 155 -- doc/spec/proposals/128-bridge-families.txt | 64 - doc/spec/proposals/129-reject-plaintext-ports.txt | 114 - doc/spec/proposals/130-v2-conn-protocol.txt | 184 -- doc/spec/proposals/131-verify-tor-usage.txt | 148 -- .../proposals/132-browser-check-tor-service.txt | 145 -- doc/spec/proposals/133-unreachable-ors.txt | 128 - doc/spec/proposals/134-robust-voting.txt | 123 - doc/spec/proposals/135-private-tor-networks.txt | 281 --- doc/spec/proposals/136-legacy-keys.txt | 100 - doc/spec/proposals/137-bootstrap-phases.txt | 235 -- .../138-remove-down-routers-from-consensus.txt | 49 - .../139-conditional-consensus-download.txt | 94 - doc/spec/proposals/140-consensus-diffs.txt | 156 -- doc/spec/proposals/141-jit-sd-downloads.txt | 323 --- .../142-combine-intro-and-rend-points.txt | 277 --- .../143-distributed-storage-improvements.txt | 194 -- .../proposals/144-enforce-distinct-providers.txt | 165 -- doc/spec/proposals/145-newguard-flag.txt | 39 - doc/spec/proposals/146-long-term-stability.txt | 84 - doc/spec/proposals/147-prevoting-opinions.txt | 58 - .../proposals/148-uniform-client-end-reason.txt | 57 - doc/spec/proposals/149-using-netinfo-data.txt | 42 - doc/spec/proposals/150-exclude-exit-nodes.txt | 47 - .../proposals/151-path-selection-improvements.txt | 148 -- doc/spec/proposals/152-single-hop-circuits.txt | 62 - .../153-automatic-software-update-protocol.txt | 175 -- doc/spec/proposals/154-automatic-updates.txt | 377 --- .../155-four-hidden-service-improvements.txt | 120 - doc/spec/proposals/156-tracking-blocked-ports.txt | 527 ----- doc/spec/proposals/157-specific-cert-download.txt | 102 - doc/spec/proposals/158-microdescriptors.txt | 198 -- doc/spec/proposals/159-exit-scanning.txt | 142 -- doc/spec/proposals/160-bandwidth-offset.txt | 105 - .../161-computing-bandwidth-adjustments.txt | 174 -- doc/spec/proposals/162-consensus-flavors.txt | 188 -- doc/spec/proposals/163-detecting-clients.txt | 115 - doc/spec/proposals/164-reporting-server-status.txt | 91 - doc/spec/proposals/165-simple-robust-voting.txt | 133 -- .../proposals/166-statistics-extra-info-docs.txt | 391 ---- doc/spec/proposals/167-params-in-consensus.txt | 47 - doc/spec/proposals/168-reduce-circwindow.txt | 134 -- .../proposals/169-eliminating-renegotiation.txt | 404 ---- doc/spec/proposals/170-user-path-config.txt | 95 - doc/spec/proposals/171-separate-streams.txt | 357 --- doc/spec/proposals/172-circ-getinfo-option.txt | 138 -- .../proposals/173-getinfo-option-expansion.txt | 101 - doc/spec/proposals/174-optimistic-data-server.txt | 242 -- .../proposals/175-automatic-node-promotion.txt | 238 -- doc/spec/proposals/176-revising-handshake.txt | 623 ----- doc/spec/proposals/177-flag-abstention.txt | 104 - doc/spec/proposals/ideas/xxx-auto-update.txt | 39 - .../proposals/ideas/xxx-bridge-disbursement.txt | 174 -- doc/spec/proposals/ideas/xxx-bwrate-algs.txt | 106 - .../ideas/xxx-choosing-crypto-in-tor-protocol.txt | 138 -- .../ideas/xxx-controllers-intercept-extends.txt | 44 - doc/spec/proposals/ideas/xxx-crypto-migration.txt | 384 --- .../proposals/ideas/xxx-crypto-requirements.txt | 72 - .../ideas/xxx-draft-spec-for-TLS-normalization.txt | 360 --- .../proposals/ideas/xxx-encrypted-services.txt | 66 - .../proposals/ideas/xxx-exit-scanning-outline.txt | 44 - doc/spec/proposals/ideas/xxx-geoip-survey-plan.txt | 137 -- .../proposals/ideas/xxx-grand-scaling-plan.txt | 97 - doc/spec/proposals/ideas/xxx-hide-platform.txt | 37 - .../proposals/ideas/xxx-pluggable-transport.txt | 312 --- doc/spec/proposals/ideas/xxx-port-knocking.txt | 91 - doc/spec/proposals/ideas/xxx-rate-limit-exits.txt | 63 - doc/spec/proposals/ideas/xxx-using-spdy.txt | 143 -- doc/spec/proposals/ideas/xxx-what-uses-sha1.txt | 247 -- doc/spec/proposals/reindex.py | 117 - doc/spec/rend-spec.txt | 966 -------- doc/spec/socks-extensions.txt | 78 - doc/spec/tor-fw-helper-spec.txt | 57 - doc/spec/tor-spec.txt | 1004 -------- doc/spec/version-spec.txt | 44 - 117 files changed, 11 insertions(+), 27211 deletions(-) diff --combined doc/Makefile.am index c8bffc9,bc3d8df..6cc0ea9 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@@ -1,4 -1,3 +1,3 @@@ - # We use a two-step process to generate documentation from asciidoc files. # # First, we use asciidoc/a2x to process the asciidoc files into .1.in and @@@ -14,11 -13,7 +13,11 @@@ # just use the .1 and .html files. if USE_ASCIIDOC +if USE_FW_HELPER +asciidoc_files = tor tor-gencert tor-resolve torify tor-fw-helper +else asciidoc_files = tor tor-gencert tor-resolve torify +endif html_in = $(asciidoc_files:=.html.in) man_in = $(asciidoc_files:=.1.in) txt_in = $(asciidoc_files:=.1.txt) @@@ -36,16 -31,12 +35,12 @@@ endi EXTRA_DIST = HACKING asciidoc-helper.sh \ $(html_in) $(man_in) $(txt_in) \ tor-rpm-creation.txt \ - tor-win32-mingw-creation.txt + tor-win32-mingw-creation.txt spec/README docdir = @docdir@ asciidoc_product = $(nodist_man_MANS) $(doc_DATA) - SUBDIRS = spec - - DIST_SUBDIRS = spec - # Generate the html documentation from asciidoc, but don't do # machine-specific replacements yet $(html_in) : @@@ -55,7 -46,6 +50,7 @@@ tor.html.in : tor.1.tx torify.html.in : torify.1.txt tor-gencert.html.in : tor-gencert.1.txt tor-resolve.html.in : tor-resolve.1.txt +tor-fw-helper.html.in : tor-fw-helper.1.txt # Generate the manpage from asciidoc, but don't do # machine-specific replacements yet @@@ -66,7 -56,6 +61,7 @@@ tor.1.in : tor.1.tx torify.1.in : torify.1.txt tor-gencert.1.in : tor-gencert.1.txt tor-resolve.1.in : tor-resolve.1.txt +tor-fw-helper.1.in : tor-fw-helper.1.txt # use ../config.status to swap all machine-specific magic strings # in the asciidoc with their replacements. @@@ -80,12 -69,10 +75,12 @@@ tor.1 : tor.1.i torify.1 : torify.1.in tor-gencert.1 : tor-gencert.1.in tor-resolve.1 : tor-resolve.1.in +tor-fw-helper.1 : tor-fw-helper.1.in tor.html : tor.html.in torify.html : torify.html.in tor-gencert.html : tor-gencert.html.in tor-resolve.html : tor-resolve.html.in +tor-fw-helper.html : tor-fw-helper.html.in CLEANFILES = $(asciidoc_product) config.log DISTCLEANFILES = $(html_in) $(man_in)

1 0