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

[tor/release-0.2.2] Handle NULL argument to get_configured_bridge_by_addr_port_digest
by arma＠torproject.org 17 May '11

17 May '11

commit 21ed575826e701437f7893536ffc5c8d2a71532f Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue May 17 19:46:47 2011 -0400 Handle NULL argument to get_configured_bridge_by_addr_port_digest Fixes bug 2313; bugfix on 0.2.2.26-beta. --- changes/bug3213 | 4 ++++ src/or/circuitbuild.c | 2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/changes/bug3213 b/changes/bug3213 new file mode 100644 index 0000000..ab7de2d --- /dev/null +++ b/changes/bug3213 @@ -0,0 +1,4 @@ + o Major bugfixes: + - Fix a crash bug when changing bridges in a running Tor process. + Fixes bug 3213; bugfix on 0.2.2.26-beta. + diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index 860cd27..2f86e1f 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -4539,7 +4539,7 @@ get_configured_bridge_by_addr_port_digest(const tor_addr_t *addr, !tor_addr_compare(&bridge->addr, addr, CMP_EXACT) && bridge->port == port) return bridge; - if (tor_memeq(bridge->identity, digest, DIGEST_LEN)) + if (digest && tor_memeq(bridge->identity, digest, DIGEST_LEN)) return bridge; } SMARTLIST_FOREACH_END(bridge);

1 0

[tor/release-0.2.2] Oops; that function got renamed.
by arma＠torproject.org 17 May '11

17 May '11

commit 2e07925a5285fd50626e853c48ab5b79eec8e933 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue May 17 19:45:05 2011 -0400 Oops; that function got renamed. --- src/or/routerparse.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/routerparse.c b/src/or/routerparse.c index 57436f7..ce98a47 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -4336,7 +4336,7 @@ microdescs_parse_from_string(const char *s, const char *eos, } tok = find_by_keyword(tokens, K_ONION_KEY); - if (!crypto_pk_check_key_public_exponent(tok->key)) { + if (!crypto_pk_public_exponent_ok(tok->key)) { log_warn(LD_DIR, "Relay's onion key had invalid exponent."); goto next;

1 0

[tor/release-0.2.2] Fix bug2752 : 48-char HTTPProxyAuthenticator limitation
by arma＠torproject.org 17 May '11

17 May '11

commit a3707a10529c3d90a06149cf0e4bcd28b7b1ab5b Author: Michael Yakubovich <e_zine99(a)yahoo.com> Date: Mon May 16 16:09:35 2011 -0400 Fix bug2752 : 48-char HTTPProxyAuthenticator limitation Bumped the char maximum to 512 for HTTPProxyAuthenticator & HTTPSProxyAuthenticator. Now stripping all '\n' after base64 encoding in alloc_http_authenticator. --- changes/bug2752 | 5 +++++ src/or/config.c | 8 ++++---- src/or/connection.c | 13 +++++++++++-- 3 files changed, 20 insertions(+), 6 deletions(-) diff --git a/changes/bug2752 b/changes/bug2752 new file mode 100644 index 0000000..328f11e --- /dev/null +++ b/changes/bug2752 @@ -0,0 +1,5 @@ + o Minor bugfixes + - Tor used to limit HttpProxyAuthenticator values to 48 characters. + Changed the limit to 512 characters by removing base64 newlines. + Fixes bug 2917. + diff --git a/src/or/config.c b/src/or/config.c index 614fc48..36a8940 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -3398,8 +3398,8 @@ options_validate(or_options_t *old_options, or_options_t *options, } if (options->HTTPProxyAuthenticator) { - if (strlen(options->HTTPProxyAuthenticator) >= 48) - REJECT("HTTPProxyAuthenticator is too long (>= 48 chars)."); + if (strlen(options->HTTPProxyAuthenticator) >= 512) + REJECT("HTTPProxyAuthenticator is too long (>= 512 chars)."); } if (options->HTTPSProxy) { /* parse it now */ @@ -3412,8 +3412,8 @@ options_validate(or_options_t *old_options, or_options_t *options, } if (options->HTTPSProxyAuthenticator) { - if (strlen(options->HTTPSProxyAuthenticator) >= 48) - REJECT("HTTPSProxyAuthenticator is too long (>= 48 chars)."); + if (strlen(options->HTTPSProxyAuthenticator) >= 512) + REJECT("HTTPSProxyAuthenticator is too long (>= 512 chars)."); } if (options->Socks4Proxy) { /* parse it now */ diff --git a/src/or/connection.c b/src/or/connection.c index 5054909..bcdde67 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -3232,8 +3232,17 @@ alloc_http_authenticator(const char *authenticator) authenticator, authenticator_length) < 0) { tor_free(base64_authenticator); /* free and set to null */ } else { - /* remove extra \n at end of encoding */ - base64_authenticator[strlen(base64_authenticator) - 1] = 0; + int i = 0, j = 0; + int len = strlen(base64_authenticator); + + /* remove all newline occurrences within the string */ + for (i=0; i < len; ++i) { + if ('\n' != base64_authenticator[i]) { + base64_authenticator[j] = base64_authenticator[i]; + ++j; + } + } + base64_authenticator[j]='\0'; } return base64_authenticator; }

1 0

[tor/master] refetch bridge descriptors in a timely fashion
by arma＠torproject.org 17 May '11

17 May '11

commit 07c5026efa4c5fac64e5f3e843eae6bea0de54db Author: Roger Dingledine <arma(a)torproject.org> Date: Mon May 16 12:58:44 2011 -0400 refetch bridge descriptors in a timely fashion When we configure a new bridge via the controller, don't wait up to ten seconds before trying to fetch its descriptor. This wasn't so bad when you listed your bridges in torrc, but it's dreadful if you configure your bridges via vidalia. --- changes/bug3198 | 4 ++++ src/or/main.c | 5 +++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/changes/bug3198 b/changes/bug3198 new file mode 100644 index 0000000..29c1685 --- /dev/null +++ b/changes/bug3198 @@ -0,0 +1,4 @@ + o Major bugfixes: + - When we configure a new bridge via the controller, don't wait up + to ten seconds before trying to fetch its descriptor. Bugfix on + 0.2.0.3-alpha; fixes bug 3198 (suggested by 2355). diff --git a/src/or/main.c b/src/or/main.c index d700f0e..2c95024 100644 --- a/src/or/main.c +++ b/src/or/main.c @@ -924,8 +924,6 @@ run_scheduled_events(time_t now) if (time_to_try_getting_descriptors < now) { update_router_descriptor_downloads(now); update_extrainfo_downloads(now); - if (options->UseBridges) - fetch_bridge_descriptors(options, now); if (router_have_minimum_dir_info()) time_to_try_getting_descriptors = now + LAZY_DESCRIPTOR_RETRY_INTERVAL; else @@ -938,6 +936,9 @@ run_scheduled_events(time_t now) now + DESCRIPTOR_FAILURE_RESET_INTERVAL; } + if (options->UseBridges) + fetch_bridge_descriptors(options, now); + /** 1b. Every MAX_SSL_KEY_LIFETIME seconds, we change our TLS context. */ if (!last_rotated_x509_certificate) last_rotated_x509_certificate = now;

1 0

[tor/master] Merge branch 'maint-0.2.2'
by arma＠torproject.org 17 May '11

17 May '11

commit 92081f3cdc2e91f7eb9954af2b647ab0bc65d047 Merge: c240efa 07c5026 Author: Roger Dingledine <arma(a)torproject.org> Date: Tue May 17 20:50:18 2011 -0400 Merge branch 'maint-0.2.2' changes/bug3198 | 4 ++++ src/or/main.c | 5 +++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --cc src/or/main.c index 389ddbd,2c95024..1554e81 --- a/src/or/main.c +++ b/src/or/main.c @@@ -1108,10 -922,8 +1108,8 @@@ run_scheduled_events(time_t now } if (time_to_try_getting_descriptors < now) { - update_router_descriptor_downloads(now); + update_all_descriptor_downloads(now); update_extrainfo_downloads(now); - if (options->UseBridges) - fetch_bridge_descriptors(options, now); if (router_have_minimum_dir_info()) time_to_try_getting_descriptors = now + LAZY_DESCRIPTOR_RETRY_INTERVAL; else

1 0

[tor/maint-0.2.2] refetch bridge descriptors in a timely fashion
by arma＠torproject.org 17 May '11

17 May '11

commit 07c5026efa4c5fac64e5f3e843eae6bea0de54db Author: Roger Dingledine <arma(a)torproject.org> Date: Mon May 16 12:58:44 2011 -0400 refetch bridge descriptors in a timely fashion When we configure a new bridge via the controller, don't wait up to ten seconds before trying to fetch its descriptor. This wasn't so bad when you listed your bridges in torrc, but it's dreadful if you configure your bridges via vidalia. --- changes/bug3198 | 4 ++++ src/or/main.c | 5 +++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/changes/bug3198 b/changes/bug3198 new file mode 100644 index 0000000..29c1685 --- /dev/null +++ b/changes/bug3198 @@ -0,0 +1,4 @@ + o Major bugfixes: + - When we configure a new bridge via the controller, don't wait up + to ten seconds before trying to fetch its descriptor. Bugfix on + 0.2.0.3-alpha; fixes bug 3198 (suggested by 2355). diff --git a/src/or/main.c b/src/or/main.c index d700f0e..2c95024 100644 --- a/src/or/main.c +++ b/src/or/main.c @@ -924,8 +924,6 @@ run_scheduled_events(time_t now) if (time_to_try_getting_descriptors < now) { update_router_descriptor_downloads(now); update_extrainfo_downloads(now); - if (options->UseBridges) - fetch_bridge_descriptors(options, now); if (router_have_minimum_dir_info()) time_to_try_getting_descriptors = now + LAZY_DESCRIPTOR_RETRY_INTERVAL; else @@ -938,6 +936,9 @@ run_scheduled_events(time_t now) now + DESCRIPTOR_FAILURE_RESET_INTERVAL; } + if (options->UseBridges) + fetch_bridge_descriptors(options, now); + /** 1b. Every MAX_SSL_KEY_LIFETIME seconds, we change our TLS context. */ if (!last_rotated_x509_certificate) last_rotated_x509_certificate = now;

1 0

[obfsproxy/master] Fix builds with old openssls
by nickm＠torproject.org 17 May '11

17 May '11

commit c483d861e3ebc6429ab7ba170dcb5d45421be604 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue May 17 19:32:36 2011 -0400 Fix builds with old openssls --- src/protocols/obfs2_crypt.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/protocols/obfs2_crypt.c b/src/protocols/obfs2_crypt.c index 0121c93..e6627ab 100644 --- a/src/protocols/obfs2_crypt.c +++ b/src/protocols/obfs2_crypt.c @@ -48,7 +48,7 @@ get_uint32(const void *ptr) return val; } #define LTC_ARGCHK(x) assert((x)) -#include "sha256.c" +#include "../sha256.c" #endif int

1 0

[obfsproxy/master] Merge remote-tracking branch 'asn/send_socks_fail_replies'
by nickm＠torproject.org 17 May '11

17 May '11

commit 938dd5c2677ee378c1423ebdae076aabe8155c1e Merge: c483d86 84139cb Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue May 17 20:31:45 2011 -0400 Merge remote-tracking branch 'asn/send_socks_fail_replies' src/network.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 38 insertions(+), 0 deletions(-)

1 0

[obfsproxy/master] Merge remote-tracking branch 'asn/bug_error_or_eof'
by nickm＠torproject.org 17 May '11

17 May '11

commit d268a156e54fe8da542c6d3c5c2e4d8bfa05b6ec Merge: 7123e54 cd64d97 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue May 17 19:27:32 2011 -0400 Merge remote-tracking branch 'asn/bug_error_or_eof' src/network.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

1 0

[obfsproxy/master] Send SOCKS responses when CONNECT fails, and also treat our connection better.
by nickm＠torproject.org 17 May '11

17 May '11

commit 84139cb2636cb22c285102eaa9b96e2e00e83a72 Author: George Kadianakis <desnacked(a)gmail.com> Date: Mon May 16 18:08:36 2011 +0200 Send SOCKS responses when CONNECT fails, and also treat our connection better. --- src/network.c | 54 ++++++++++++++++++++++++++++++++++++++---------------- 1 files changed, 38 insertions(+), 16 deletions(-) diff --git a/src/network.c b/src/network.c index 66b3f59..b0106de 100644 --- a/src/network.c +++ b/src/network.c @@ -341,27 +341,49 @@ output_event_cb(struct bufferevent *bev, short what, void *arg) conn_t *conn = arg; assert(bev == conn->output); - if (conn->flushing || (what & (BEV_EVENT_EOF))) { + /** + If we got the BEV_EVENT_ERROR flag *AND* we are in socks mode + *AND* we are in the ST_HAVE_ADDR state, chances are that we + failed connecting to the host requested by the CONNECT call. This + means that we should send a negative SOCKS reply back to the + client and terminate the connection. + */ + if (what & BEV_EVENT_ERROR) { + if ((conn->mode == LSN_SOCKS_CLIENT) && + (conn->socks_state) && + (socks_state_get_status(conn->socks_state) == ST_HAVE_ADDR)) { + dbg(("Connection failed\n")); + /* Enable EV_WRITE so that we can send the response. + Disable EV_READ so that we don't get more stuff from the client. */ + bufferevent_enable(conn->input, EV_WRITE); + bufferevent_disable(conn->input, EV_READ); + socks_send_reply(conn->socks_state, bufferevent_get_output(conn->input), + SOCKS5_REP_FAIL); + bufferevent_setcb(conn->input, NULL, + close_conn_on_flush, output_event_cb, conn); + return; + } + } + + /** + If the connection is terminating *OR* if we got a BEV_EVENT_ERROR + but we don't match the case above, we most probably have to close + this connection soon. + */ + if (conn->flushing || (what & (BEV_EVENT_EOF|BEV_EVENT_ERROR))) { printf("Got error: %s\n", evutil_socket_error_to_string(EVUTIL_SOCKET_ERROR())); error_or_eof(conn, bev, conn->input); return; } - /* ASN PROBABLY connect failed and we should send a "fail" SOCKS - response. (or maybe not. I should check all the cases where - BEV_EVENT_ERROR is waved) */ - if (what & BEV_EVENT_ERROR) { - /* assert(conn->socks_state) ? */ - if (conn->socks_state) { - if (socks_state_get_status(conn->socks_state) == ST_HAVE_ADDR) { - dbg(("Connection failed\n")); - bufferevent_enable(conn->input, EV_READ|EV_WRITE); - socks_send_reply(conn->socks_state, bufferevent_get_output(conn->input), - SOCKS5_REP_FAIL); - return; - } - } - } + + /** + If we got the BEV_EVENT_CONNECTED flag it means that a connection + request was succesfull and normally that should have been off a + CONNECT request by the SOCKS client. If that's the case we should + send a happy response to the client and switch to start serving + our pluggable transport protocol. + */ if (what & BEV_EVENT_CONNECTED) { /* woo, we're connected. Now the input buffer can start reading. */ conn->is_open = 1;

1 0