- tor-commits - lists.torproject.org

[tor/master] defensive programming to catch duplicate calls to connection_init_or_handshake_state
by nickm＠torproject.org 11 Jan '12

11 Jan '12

commit ce703bd53edec2ee123dd747d6cc975a259c68f9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Oct 26 20:19:25 2011 -0400 defensive programming to catch duplicate calls to connection_init_or_handshake_state --- src/or/connection_or.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/or/connection_or.c b/src/or/connection_or.c index 7609138..76402a5 100644 --- a/src/or/connection_or.c +++ b/src/or/connection_or.c @@ -1583,6 +1583,10 @@ int connection_init_or_handshake_state(or_connection_t *conn, int started_here) { or_handshake_state_t *s; + if (conn->handshake_state) { + log_warn(LD_BUG, "Duplicate call to connection_init_or_handshake_state!"); + return 0; + } s = conn->handshake_state = tor_malloc_zero(sizeof(or_handshake_state_t)); s->started_here = started_here ? 1 : 0; s->digest_sent_data = 1;

1 0

[tor/master] Merge branch 'prop187_squashed'
by nickm＠torproject.org 11 Jan '12

11 Jan '12

commit f54a10caa62db6653cd8f5a8c84de3a623428c6c Merge: fa83397 3826e05 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 11 12:27:14 2012 -0500 Merge branch 'prop187_squashed' src/or/command.c | 75 +++++++++++++++++++++++++++++++++++++---------- src/or/connection_or.c | 4 ++ src/or/or.h | 1 + 3 files changed, 64 insertions(+), 16 deletions(-)

1 0

[tor/master] Implement proposal 187: reserve a cell type for client authorization
by nickm＠torproject.org 11 Jan '12

11 Jan '12

commit 3826e058acfc1886fcd4be18644ea130d12ca9be Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Oct 26 20:19:29 2011 -0400 Implement proposal 187: reserve a cell type for client authorization This needs a changes file and more testing. --- src/or/command.c | 75 ++++++++++++++++++++++++++++++++++++++++++----------- src/or/or.h | 1 + 2 files changed, 60 insertions(+), 16 deletions(-) diff --git a/src/or/command.c b/src/or/command.c index 023f2be..6c1312b 100644 --- a/src/or/command.c +++ b/src/or/command.c @@ -54,6 +54,8 @@ uint64_t stats_n_certs_cells_processed = 0; uint64_t stats_n_auth_challenge_cells_processed = 0; /** How many CELL_AUTHENTICATE cells have we received, ever? */ uint64_t stats_n_authenticate_cells_processed = 0; +/** How many CELL_AUTHORIZE cells have we received, ever? */ +uint64_t stats_n_authorize_cells_processed = 0; /* These are the main functions for processing cells */ static void command_process_create_cell(cell_t *cell, or_connection_t *conn); @@ -69,6 +71,8 @@ static void command_process_auth_challenge_cell(var_cell_t *cell, or_connection_t *conn); static void command_process_authenticate_cell(var_cell_t *cell, or_connection_t *conn); +static int enter_v3_handshake_with_cell(var_cell_t *cell, + or_connection_t *conn); #ifdef KEEP_TIMING_STATS /** This is a wrapper function around the actual function that processes the @@ -203,6 +207,22 @@ command_process_cell(cell_t *cell, or_connection_t *conn) } } +/** Return true if <b>command</b> is a cell command that's allowed to start a + * V3 handshake. */ +static int +command_allowed_before_handshake(uint8_t command) +{ + switch (command) { + case CELL_PADDING: /*XXXX not implemented. Should remove, or implement? */ + case CELL_VERSIONS: + case CELL_VPADDING: + case CELL_AUTHORIZE: + return 1; + default: + return 0; + } +} + /** Process a <b>cell</b> that was just received on <b>conn</b>. Keep internal * statistics about how many of each cell we've processed so far * this second, and the total number of microseconds it took to @@ -250,13 +270,16 @@ command_process_var_cell(var_cell_t *cell, or_connection_t *conn) /* fall through */ case OR_CONN_STATE_TLS_SERVER_RENEGOTIATING: - if (cell->command != CELL_VERSIONS) { + if (! command_allowed_before_handshake(cell->command)) { log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL, - "Received a non-VERSIONS cell with command %d in state %s; " + "Received a cell with command %d in state %s; " "ignoring it.", (int)cell->command, conn_state_to_string(CONN_TYPE_OR,conn->_base.state)); return; + } else { + if (enter_v3_handshake_with_cell(cell, conn)<0) + return; } break; case OR_CONN_STATE_OR_HANDSHAKING_V3: @@ -305,6 +328,10 @@ command_process_var_cell(var_cell_t *cell, or_connection_t *conn) ++stats_n_authenticate_cells_processed; PROCESS_CELL(authenticate, cell, conn); break; + case CELL_AUTHORIZE: + ++stats_n_authorize_cells_processed; + /* Ignored so far. */ + break; default: log_fn(LOG_INFO, LD_PROTOCOL, "Variable-length cell of unknown type (%d) received.", @@ -592,6 +619,35 @@ command_process_destroy_cell(cell_t *cell, or_connection_t *conn) } } +/** Called when we as a server receive an appropriate cell while waiting + * either for a cell or a TLS handshake. Set the connection's state to + * "handshaking_v3', initializes the or_handshake_state field as needed, + * and add the cell to the hash of incoming cells.) + * + * Return 0 on success; return -1 and mark the connection on failure. + */ +static int +enter_v3_handshake_with_cell(var_cell_t *cell, or_connection_t *conn) +{ + const int started_here = connection_or_nonopen_was_started_here(conn); + + tor_assert(conn->_base.state == OR_CONN_STATE_TLS_HANDSHAKING || + conn->_base.state == OR_CONN_STATE_TLS_SERVER_RENEGOTIATING); + + if (started_here) { + log_fn(LOG_PROTOCOL_WARN, LD_OR, + "Received a cell while TLS-handshaking, not in " + "OR_HANDSHAKING_V3, on a connection we originated."); + } + conn->_base.state = OR_CONN_STATE_OR_HANDSHAKING_V3; + if (connection_init_or_handshake_state(conn, started_here) < 0) { + connection_mark_for_close(TO_CONN(conn)); + return -1; + } + or_handshake_state_record_var_cell(conn->handshake_state, cell, 1); + return 0; +} + /** Process a 'versions' cell. The current link protocol version must be 0 * to indicate that no version has yet been negotiated. We compare the * versions in the cell to the list of versions we support, pick the @@ -614,23 +670,10 @@ command_process_versions_cell(var_cell_t *cell, or_connection_t *conn) switch (conn->_base.state) { case OR_CONN_STATE_OR_HANDSHAKING_V2: + case OR_CONN_STATE_OR_HANDSHAKING_V3: break; case OR_CONN_STATE_TLS_HANDSHAKING: case OR_CONN_STATE_TLS_SERVER_RENEGOTIATING: - if (started_here) { - log_fn(LOG_PROTOCOL_WARN, LD_OR, - "Received a versions cell while TLS-handshaking not in " - "OR_HANDSHAKING_V3 on a connection we originated."); - } - conn->_base.state = OR_CONN_STATE_OR_HANDSHAKING_V3; - if (connection_init_or_handshake_state(conn, started_here) < 0) { - connection_mark_for_close(TO_CONN(conn)); - return; - } - or_handshake_state_record_var_cell(conn->handshake_state, cell, 1); - break; - case OR_CONN_STATE_OR_HANDSHAKING_V3: - break; default: log_fn(LOG_PROTOCOL_WARN, LD_OR, "VERSIONS cell while in unexpected state"); diff --git a/src/or/or.h b/src/or/or.h index 8fe3e0f..a7a517f 100644 --- a/src/or/or.h +++ b/src/or/or.h @@ -833,6 +833,7 @@ typedef enum { #define CELL_CERTS 129 #define CELL_AUTH_CHALLENGE 130 #define CELL_AUTHENTICATE 131 +#define CELL_AUTHORIZE 132 /** How long to test reachability before complaining to the user. */ #define TIMEOUT_UNTIL_UNREACHABILITY_COMPLAINT (20*60)

1 0

[tor/master] Do not pretend to allow PADDING as the first cell of a v3 handshake
by nickm＠torproject.org 11 Jan '12

11 Jan '12

commit b8675e5fe35a737078b210d5c5c7440af3f2b145 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 11 12:34:28 2012 -0500 Do not pretend to allow PADDING as the first cell of a v3 handshake --- src/or/command.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/or/command.c b/src/or/command.c index 6c1312b..a23e47f 100644 --- a/src/or/command.c +++ b/src/or/command.c @@ -213,7 +213,6 @@ static int command_allowed_before_handshake(uint8_t command) { switch (command) { - case CELL_PADDING: /*XXXX not implemented. Should remove, or implement? */ case CELL_VERSIONS: case CELL_VPADDING: case CELL_AUTHORIZE:

1 0

[torspec/master] proposal 190 got renamed.
by nickm＠torproject.org 11 Jan '12

11 Jan '12

commit a04a6f1412ca709d003e7acb07c13b9e91540e7a Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 11 12:33:31 2012 -0500 proposal 190 got renamed. --- proposals/190-password-bridge-authorization.txt | 101 -------------------- .../190-shared-secret-bridge-authorization.txt | 101 ++++++++++++++++++++ 2 files changed, 101 insertions(+), 101 deletions(-) diff --git a/proposals/190-password-bridge-authorization.txt b/proposals/190-password-bridge-authorization.txt deleted file mode 100644 index 95a0d19..0000000 --- a/proposals/190-password-bridge-authorization.txt +++ /dev/null @@ -1,101 +0,0 @@ -Filename: 190-shared-secret-bridge-authorization.txt -Title: Bridge Client Authorization Based on a Shared Secret -Author: George Kadianakis -Created: 04 Nov 2011 -Status: Open - -1. Overview - - Proposals 187 and 189 introduced AUTHORIZE and AUTHORIZED cells. - Their purpose is to make bridge relays scanning resistant against - censoring adversaries capable of probing hosts to observe whether - they speak the Tor protocol. - - This proposal specifies a bridge client authorization scheme based - on a shared secret between the bridge user and bridge operator. - -2. Motivation - - A bridge client authorization scheme should only allow clients who - show knowledge of a shared secret to talk Tor to the bridge. - -3. Shared-secret-based authorization - -3.1. Where do shared secrets come from? - - A shared secret is a piece of data known only to the bridge - operator and the bridge client. - - It's meant to be automatically generated by the bridge - implementation to avoid issues with insecure and weak passwords. - - Bridge implementations SHOULD create shared secrets by generating - random data using a strong RNG or PRNG. - -3.2. AUTHORIZE cell format - - In shared-secret-based authorization, the MethodFields field of the - AUTHORIZE cell becomes: - - 'shared_secret' [10 octets] - - where: - - 'shared_secret', is the shared secret between the bridge operator - and the bridge client. - -3.3. Cell parsing - - Bridge implementations MUST reject any AUTHORIZE cells whose - 'shared_secret' field does not match the shared secret negotiated - between the bridge operator and authorized bridge clients. - -4. Tor implementation - -4.1. Bridge side - - Tor bridge implementations MUST create the bridge shared secret by - generating 10 octets of random data using a strong RNG or PRNG. - - Tor bridge implementations MUST store the shared secret in - 'DataDirectory/keys/bridge_auth_ss_key' in hexademical encoding. - - Tor bridge implementations MUST support the boolean - 'BridgeRequireClientSharedSecretAuthorization' configuration file - option which enables bridge client authorization based on a shared - secret. - - If 'BridgeRequireClientSharedSecretAuthorization' is set, bridge - implementations MUST generate a new shared secret, if - 'DataDirectory/keys/bridge_auth_ss_key' does not already exist. - -4.2. Client side - - Tor client implementations must extend their Bridge line format to - support bridge shared secrets. The new format is: - Bridge <method> <address:port> [["keyid="]<id-fingerprint>] ["shared_secret="<shared_secret>] - - where <shared_secret> is the bridge shared secret in hexademical - encoding. - - Tor clients who use bridges with shared-secret-based client - authorization must specify the bridge's shared secret as in: - Bridge 12.34.56.78 shared_secret=934caff420aa7852b855 - -5. Discussion - -5.1. What should actually happen when a bridge rejects an AUTHORIZE - cell? - - When a bridge detects a badly formed or malicious AUTHORIZE cell, - it should assume that the other side is an adversary scanning for - bridges. The bridge should then act accordingly to avoid detection. - - This proposal does not try to specify how a bridge can avoid - detection by an adversary. - -6. Acknowledgements - - Thanks to Nick Mathewson and Robert Ransom for the help and - suggestions while writing this proposal. - diff --git a/proposals/190-shared-secret-bridge-authorization.txt b/proposals/190-shared-secret-bridge-authorization.txt new file mode 100644 index 0000000..95a0d19 --- /dev/null +++ b/proposals/190-shared-secret-bridge-authorization.txt @@ -0,0 +1,101 @@ +Filename: 190-shared-secret-bridge-authorization.txt +Title: Bridge Client Authorization Based on a Shared Secret +Author: George Kadianakis +Created: 04 Nov 2011 +Status: Open + +1. Overview + + Proposals 187 and 189 introduced AUTHORIZE and AUTHORIZED cells. + Their purpose is to make bridge relays scanning resistant against + censoring adversaries capable of probing hosts to observe whether + they speak the Tor protocol. + + This proposal specifies a bridge client authorization scheme based + on a shared secret between the bridge user and bridge operator. + +2. Motivation + + A bridge client authorization scheme should only allow clients who + show knowledge of a shared secret to talk Tor to the bridge. + +3. Shared-secret-based authorization + +3.1. Where do shared secrets come from? + + A shared secret is a piece of data known only to the bridge + operator and the bridge client. + + It's meant to be automatically generated by the bridge + implementation to avoid issues with insecure and weak passwords. + + Bridge implementations SHOULD create shared secrets by generating + random data using a strong RNG or PRNG. + +3.2. AUTHORIZE cell format + + In shared-secret-based authorization, the MethodFields field of the + AUTHORIZE cell becomes: + + 'shared_secret' [10 octets] + + where: + + 'shared_secret', is the shared secret between the bridge operator + and the bridge client. + +3.3. Cell parsing + + Bridge implementations MUST reject any AUTHORIZE cells whose + 'shared_secret' field does not match the shared secret negotiated + between the bridge operator and authorized bridge clients. + +4. Tor implementation + +4.1. Bridge side + + Tor bridge implementations MUST create the bridge shared secret by + generating 10 octets of random data using a strong RNG or PRNG. + + Tor bridge implementations MUST store the shared secret in + 'DataDirectory/keys/bridge_auth_ss_key' in hexademical encoding. + + Tor bridge implementations MUST support the boolean + 'BridgeRequireClientSharedSecretAuthorization' configuration file + option which enables bridge client authorization based on a shared + secret. + + If 'BridgeRequireClientSharedSecretAuthorization' is set, bridge + implementations MUST generate a new shared secret, if + 'DataDirectory/keys/bridge_auth_ss_key' does not already exist. + +4.2. Client side + + Tor client implementations must extend their Bridge line format to + support bridge shared secrets. The new format is: + Bridge <method> <address:port> [["keyid="]<id-fingerprint>] ["shared_secret="<shared_secret>] + + where <shared_secret> is the bridge shared secret in hexademical + encoding. + + Tor clients who use bridges with shared-secret-based client + authorization must specify the bridge's shared secret as in: + Bridge 12.34.56.78 shared_secret=934caff420aa7852b855 + +5. Discussion + +5.1. What should actually happen when a bridge rejects an AUTHORIZE + cell? + + When a bridge detects a badly formed or malicious AUTHORIZE cell, + it should assume that the other side is an adversary scanning for + bridges. The bridge should then act accordingly to avoid detection. + + This proposal does not try to specify how a bridge can avoid + detection by an adversary. + +6. Acknowledgements + + Thanks to Nick Mathewson and Robert Ransom for the help and + suggestions while writing this proposal. +

1 0

[torspec/master] Add AUTHORIZE cell type to tor-spec.txt from prop187
by nickm＠torproject.org 11 Jan '12

11 Jan '12

commit 363c86587df057f1b2cd1ba429d6a0a8873ee983 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 11 12:33:56 2012 -0500 Add AUTHORIZE cell type to tor-spec.txt from prop187 --- proposals/000-index.txt | 8 ++++---- proposals/187-allow-client-auth.txt | 2 +- tor-spec.txt | 12 ++++++++++-- 3 files changed, 15 insertions(+), 7 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 950bc38..92669b9 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -107,10 +107,10 @@ Proposals by number: 184 Miscellaneous changes for a v3 Tor link protocol [CLOSED] 185 Directory caches without DirPort [OPEN] 186 Multiple addresses for one OR or bridge [DRAFT] -187 Reserve a cell type to allow client authorization [OPEN] +187 Reserve a cell type to allow client authorization [CLOSED] 188 Bridge Guards and other anti-enumeration defenses [OPEN] 189 AUTHORIZE and AUTHORIZED cells [OPEN] -190 Password-based Bridge Client Authorization [OPEN] +190 Bridge Client Authorization Based on a Shared Secret [OPEN] 191 Bridge Detection Resistance against MITM-capable Adversaries [OPEN] 192 Automatically retrieve and store information about bridges [OPEN] @@ -142,10 +142,9 @@ Proposals by status: 177 Abstaining from votes on individual flags [for 0.2.3.x] 180 Pluggable transports for circumvention [for 0.2.3.x] 185 Directory caches without DirPort - 187 Reserve a cell type to allow client authorization [for 0.2.3.x] 188 Bridge Guards and other anti-enumeration defenses 189 AUTHORIZE and AUTHORIZED cells - 190 Password-based Bridge Client Authorization + 190 Bridge Client Authorization Based on a Shared Secret 191 Bridge Detection Resistance against MITM-capable Adversaries 192 Automatically retrieve and store information about bridges [for 0.2.[45].x] ACCEPTED: @@ -205,6 +204,7 @@ Proposals by status: 181 Optimistic Data for Tor: Client Side [in 0.2.3.3-alpha] 183 Refill Intervals [in 0.2.3.5-alpha] 184 Miscellaneous changes for a v3 Tor link protocol [for 0.2.3.x] + 187 Reserve a cell type to allow client authorization [for 0.2.3.x] SUPERSEDED: 112 Bring Back Pathlen Coin Weight 113 Simplifying directory authority administration diff --git a/proposals/187-allow-client-auth.txt b/proposals/187-allow-client-auth.txt index 6a9e2da..67c878e 100644 --- a/proposals/187-allow-client-auth.txt +++ b/proposals/187-allow-client-auth.txt @@ -2,7 +2,7 @@ Filename: 187-allow-client-auth.txt Title: Reserve a cell type to allow client authorization Author: Nick Mathewson Created: 16-Oct-2011 -Status: Open +Status: Closed Target: 0.2.3.x Overview: diff --git a/tor-spec.txt b/tor-spec.txt index 28eca98..fea3073 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -345,6 +345,7 @@ see tor-design.pdf. 129 -- CERTS (Certificates) (See Sec 4.2) 130 -- AUTH_CHALLENGE (Challenge value) (See Sec 4.3) 131 -- AUTHENTICATE (Client authentication)(See Sec 4.5) + 132 -- AUTHORIZE (Client authorization) (Not yet used) The interpretation of 'Payload' depends on the type of the cell. PADDING: Payload is unused. @@ -399,8 +400,15 @@ see tor-design.pdf. authenticate, it waits until it gets the AUTH_CHALLENGE cell, and then sends a CERTS cell, an AUTHENTICATE cell (4.4), and a NETINFO cell. When this handshake is in use, the first cell must - still be VERSIONS, and no other cell type is allowed to intervene - besides those specified, except for PADDING and VPADDING cells. + be VERSIONS, VPADDING or AUTHORIZE, and no other cell type is allowed to + intervene besides those specified, except for PADDING and VPADDING cells. + + The AUTHORIZE cell type is reserved for future use by scanning-resistance + designs. + + [Tor versions before 0.2.3.11-alpha did not recognize the AUTHORIZE cell, + and did not permit any command other than VERSIONS as the first cell of + the in-protocol handshake.] 4.1. Negotiating versions with VERSIONS cells

1 0

[tor/master] Fix a missing iso_time_nospace_usec
by nickm＠torproject.org 11 Jan '12

11 Jan '12

commit fa83397ecdba136af4b493a4bf70ef752356fde2 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 11 12:23:43 2012 -0500 Fix a missing iso_time_nospace_usec Apparently I missed a case when converting sec,usec to yyyy-mm-ddThh:mm:ss.uuuuuu . --- src/or/control.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/or/control.c b/src/or/control.c index debf0f0..a939946 100644 --- a/src/or/control.c +++ b/src/or/control.c @@ -3420,14 +3420,15 @@ control_event_circuit_status_minor(origin_circuit_t *circ, const char *hs_state_str = circuit_purpose_to_controller_hs_state_string(purpose); const struct timeval *old_timestamp_created = tv; + char tbuf[ISO_TIME_USEC_LEN+1]; + format_iso_time_nospace_usec(tbuf, old_timestamp_created); tor_snprintf(event_tail, sizeof(event_tail), - " OLD_PURPOSE=%s%s%s OLD_TIME_CREATED=%ld,%ld", + " OLD_PURPOSE=%s%s%s OLD_TIME_CREATED=%s", circuit_purpose_to_controller_string(purpose), (hs_state_str != NULL) ? " OLD_HS_STATE=" : "", (hs_state_str != NULL) ? hs_state_str : "", - old_timestamp_created->tv_sec, - old_timestamp_created->tv_usec); + tbuf); } break;

1 0

r25303: {website} Adding stem to volunteer table and editing activity Updating (website/trunk/getinvolved/en)
by Damian Johnson 11 Jan '12

11 Jan '12

Author: atagar Date: 2012-01-11 17:23:06 +0000 (Wed, 11 Jan 2012) New Revision: 25303 Modified: website/trunk/getinvolved/en/volunteer.wml Log: Adding stem to volunteer table and editing activity Updating project activity as per the last couple months of commits, and adding Stem to the project table (people gsathya talked with were confused since it wasn't there). Modified: website/trunk/getinvolved/en/volunteer.wml =================================================================== --- website/trunk/getinvolved/en/volunteer.wml 2012-01-11 16:59:44 UTC (rev 25302) +++ website/trunk/getinvolved/en/volunteer.wml 2012-01-11 17:23:06 UTC (rev 25303) @@ -117,7 +117,7 @@ <td><a href="#project-torsocks">Torsocks</a></td> <td>Usability</td> <td>C</td> - <td>Light</td> + <td>None</td> <td>mwenge</td> </tr> @@ -178,6 +178,14 @@ </tr> <tr> + <td>*<a href="#project-stem">Stem</a></td> + <td>Library</td> + <td>Python</td> + <td>Heavy</td> + <td>atagar</td> + </tr> + + <tr class="alt"> <td><a href="#project-metrics">Metrics</a></td> <td>Client Service</td> <td>Java</td> @@ -185,7 +193,7 @@ <td>karsten</td> </tr> - <tr class="alt"> + <tr> <td><a href="#project-torstatus">TorStatus</a></td> <td>Client Service</td> <td>PHP</td> @@ -193,23 +201,23 @@ <td></td> </tr> - <tr> + <tr class="alt"> <td><a href="#project-weather">Weather</a></td> <td>Client Service</td> <td>Python</td> - <td>Light</td> + <td>None</td> <td>kaner</td> </tr> - <tr class="alt"> + <tr> <td><a href="#project-gettor">GetTor</a></td> <td>Client Service</td> <td>Python</td> - <td>Light</td> + <td>None</td> <td>kaner</td> </tr> - <tr> + <tr class="alt"> <td><a href="#project-torcheck">TorCheck</a></td> <td>Client Service</td> <td>Python, Perl</td> @@ -217,23 +225,23 @@ <td></td> </tr> - <tr class="alt"> + <tr> <td><a href="#project-bridgedb">BridgeDB</a></td> <td>Backend Service</td> <td>Python</td> - <td>Moderate</td> + <td>None</td> <td>kaner, nickm</td> </tr> - <tr> + <tr class="alt"> <td><a href="#project-torflow">TorFlow</a></td> <td>Backend Service</td> <td>Python</td> - <td>Light</td> + <td>Moderate</td> <td>mikeperry</td> </tr> - <tr class="alt"> + <tr> <td>*<a href="#project-torbel">TorBEL</a></td> <td>Backend Service</td> <td>Python</td> @@ -445,6 +453,17 @@ stable for several years, with only minor revisions. </p> + <a id="project-stem"></a> + <h3><a href="https://trac.torproject.org/projects/tor/wiki/doc/stem">Stem</a> (<a + href="https://gitweb.torproject.org/stem.git">code</a>, <a + href="https://trac.torproject.org/projects/tor/query?status=accepted&status=assig…">bug + tracker</a>)</h3> + + <p> + Python controller library with a similar scope to TorCtl, but with better + testing, documentation, and API. This project is not yet feature complete. + </p> + <a id="project-metrics"></a> <h3><a href="https://metrics.torproject.org/">Metrics</a> (code: <a href="https://gitweb.torproject.org/metrics-db.git">db</a>, <a

1 0

[torspec/master] Explicitly allow future new types of CIRC2 events
by nickm＠torproject.org 11 Jan '12

11 Jan '12

commit c2627218b11819577007504096d14f90e49a7e19 Author: Robert Ransom <rransom.8774(a)gmail.com> Date: Sun Jun 26 10:54:57 2011 -0700 Explicitly allow future new types of CIRC2 events --- control-spec.txt | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/control-spec.txt b/control-spec.txt index e76f377..664ff0c 100644 --- a/control-spec.txt +++ b/control-spec.txt @@ -1922,6 +1922,8 @@ "PURPOSE_CHANGED" / ; circuit purpose or HS-related state changed "CANNIBALIZED" ; circuit cannibalized + Clients MUST accept circuit events not listed above. + The "OLD_PURPOSE" field is provided for both PURPOSE_CHANGED and CANNIBALIZED events. The "OLD_HS_STATE" field is provided whenever the "OLD_PURPOSE" field is provided and is a hidden-service-related

1 0

[torspec/master] Document CIRC2 event
by nickm＠torproject.org 11 Jan '12

11 Jan '12

commit e195a4c8d288eb27385060740b8fde170a5e3e38 Author: Robert Ransom <rransom.8774(a)gmail.com> Date: Sun Jun 26 07:32:51 2011 -0700 Document CIRC2 event --- control-spec.txt | 25 ++++++++++++++++++++++++- 1 files changed, 24 insertions(+), 1 deletions(-) diff --git a/control-spec.txt b/control-spec.txt index aa04120..e76f377 100644 --- a/control-spec.txt +++ b/control-spec.txt @@ -231,7 +231,8 @@ "INFO" / "NOTICE" / "WARN" / "ERR" / "NEWDESC" / "ADDRMAP" / "AUTHDIR_NEWDESCS" / "DESCCHANGED" / "STATUS_GENERAL" / "STATUS_CLIENT" / "STATUS_SERVER" / "GUARD" / "NS" / "STREAM_BW" / - "CLIENTS_SEEN" / "NEWCONSENSUS" / "BUILDTIMEOUT_SET" / "SIGNAL" + "CLIENTS_SEEN" / "NEWCONSENSUS" / "BUILDTIMEOUT_SET" / "SIGNAL" / + "CIRC2" Any events *not* listed in the SETEVENTS line are turned off; thus, sending SETEVENTS with an empty body turns off all event reporting. @@ -1908,6 +1909,28 @@ [First added in 0.2.3.1-alpha] +4.1.18. Circuit status changed slightly + + The syntax is: + + "650" SP "CIRC2" SP CircuitID SP CircEvent [SP Path] + [SP "BUILD_FLAGS=" BuildFlags] [SP "PURPOSE=" Purpose] + [SP "HS_STATE=" HSState] [SP "REND_QUERY=" HSAddress] + [SP "OLD_PURPOSE=" Purpose [SP "OLD_HS_STATE=" HSState]] CRLF + + CircEvent = + "PURPOSE_CHANGED" / ; circuit purpose or HS-related state changed + "CANNIBALIZED" ; circuit cannibalized + + The "OLD_PURPOSE" field is provided for both PURPOSE_CHANGED and + CANNIBALIZED events. The "OLD_HS_STATE" field is provided whenever + the "OLD_PURPOSE" field is provided and is a hidden-service-related + purpose. + + Other fields are as specified in section 4.1.1 above. + + [First added in 0.2.3.2-alpha] + 5. Implementation notes 5.1. Authentication

1 0