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

[torspec/master] renumber 260
by arma＠torproject.org 12 Feb '16

12 Feb '16

commit 2d7a01399b49749a71d760818ef3f0c9c8799cf5 Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Feb 11 23:29:42 2016 -0500 renumber 260 --- proposals/260-rend-single-onion.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/proposals/260-rend-single-onion.txt b/proposals/260-rend-single-onion.txt index 79990a8..48aa794 100644 --- a/proposals/260-rend-single-onion.txt +++ b/proposals/260-rend-single-onion.txt @@ -200,7 +200,7 @@ Status: Draft And turning off hidden service server preemptive circuits, which is currently unimplemented (#17360) -5.1.3 Recommended Additional Options: Security +5.1.4 Recommended Additional Options: Security We recommend that no other services are run on a rendezvous single onion service tor instance. Since tor runs as a client (and not a relay) by @@ -275,7 +275,7 @@ Status: Draft extend. This is useful for the transition period where not all clients support single onion services. -6.5. Proposal 255 ("Hidden Service Load Balancing") +6.6. Proposal 255 ("Hidden Service Load Balancing") This proposal is compatible with proposal 255. The onion service will perform the rendezvous protocol in the same manner as any other onion @@ -316,7 +316,7 @@ Status: Draft been performed. In addition, a potential drawback is overloading a busy single onion service. -6.4 Predicted circuits +7.4 Predicted circuits We should look whether we can optimize further the predicted circuits that Tor makes as an onion service for this mode. @@ -458,3 +458,4 @@ splitting described in section 8. Here are some initial ideas. This option is disabled in Tor Browser by default. Perhaps some users would be more comfortable enabling submission over an onion service, due to the additional security benefits. +

1 0

[torspec/master] grammar/etc clarifications while reading proposal 260
by arma＠torproject.org 12 Feb '16

12 Feb '16

commit b6b2d248ca9b51876eb841c545c6641c1697aac0 Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Feb 11 23:11:35 2016 -0500 grammar/etc clarifications while reading proposal 260 --- proposals/260-rend-single-onion.txt | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/proposals/260-rend-single-onion.txt b/proposals/260-rend-single-onion.txt index fc01551..79990a8 100644 --- a/proposals/260-rend-single-onion.txt +++ b/proposals/260-rend-single-onion.txt @@ -29,10 +29,10 @@ Status: Draft 2. Motivation Rendezvous single onion services are best used by sites which: - * Don’t require location anonymity + * Don't require location anonymity * Would appreciate lower latency or self-authenticated addresses * Would like to work with existing tor clients and relays - * Can’t accept connections to an open ORPort + * Can't accept connections to an open ORPort Rendezvous single onion services have a few benefits over double onion services: @@ -61,7 +61,7 @@ Status: Draft * Connection latency is higher, as one-hop circuits are built to the introduction and rendezvous points. Single onion services perform one - extend to the single onion service’s ORPort only + extend to the single onion service's ORPort only It should also be noted that, while single onion services receive many incoming connections from different relays, rendezvous single onion @@ -99,8 +99,8 @@ Status: Draft further discussion of security issues.) (Please note that this proposal follows the hop counting conventions in the - tor source code. A circuit with a single connections between the client and - the endpoint is one-hop, a circuit with 4 connections (and 3 nodes) between + tor source code. A circuit with a single connection between the client and + the endpoint is one-hop; a circuit with 4 connections (and 3 nodes) between the client and endpoint is four-hop.) 5. Publishing a rendezvous single onion service @@ -109,11 +109,11 @@ Status: Draft group of tor instances) must: * Publish onion descriptors in the same manner as any onion service, - using three-hop circuits. This avoids service blocking by IP address, - proposal #224 (next-generation hidden services) avoids blocking by + using three-hop circuits. This avoids service blocking by IP address. + Proposal #224 (next-generation hidden services) avoids blocking by onion address. * Perform the rendezvous protocol in the same manner as a double - onion service, but make the intro and rendezvous connections one-hop. + onion service, but make the intro and rendezvous circuits one-hop. (This may allow intro and rendezvous points to block the service.) 5.1. Configuration options @@ -130,10 +130,10 @@ Status: Draft a Rendezvous Single Onion Service. (Default: 0) Because of the grave consequences of misconfiguration here, we have added - ‘NonAnonymous’ to the name of the torrc option. Furthermore, Tor MUST issue + 'NonAnonymous' to the name of the torrc option. Furthermore, Tor MUST issue a startup warning message to operators of the onion service if this feature is enabled. - [Should the name start with ‘NonAnonymous’ instead?] + [Should the name start with 'NonAnonymous' instead?] As RendezvousSingleOnionServiceNonAnonymousServer modifies the behaviour of every onion service on a tor instance, it is impossible to run hidden @@ -271,7 +271,7 @@ Status: Draft service, or continue with the rendezvous protocol. Running a rendezvous single onion service and single onion service allows - older clients to connect via rendezvous, and newer clients to connenct via + older clients to connect via rendezvous, and newer clients to connect via extend. This is useful for the transition period where not all clients support single onion services. @@ -319,7 +319,7 @@ Status: Draft 6.4 Predicted circuits We should look whether we can optimize further the predicted circuits that - Tor makes as a onion service for this mode. + Tor makes as an onion service for this mode. 8. Security Implications @@ -342,7 +342,7 @@ Status: Draft single onion services due to their benefits. This could increase the traffic on the tor network, therefore increasing anonymity overall. However, the unique behaviour of each type of onion service may still be - distinguishable from both the client and server ends of the connection. + distinguishable on both the client and server ends of the connection. 8.2 Hidden Service Designs can potentially be more secure @@ -352,9 +352,9 @@ Status: Draft 8.3 One-hop onion service paths may encourage more attacks - There's a possible second-order effect here since both encrypted - services and hidden services will have foo.onion addresses and it's - not clear based on the address whether the service will be hidden -- + There's a possible second-order effect here since both RSOS + and double onion services will have foo.onion addresses and it's + not clear based on the address which one the service uses: if *some* .onion addresses are easy to track down, are we encouraging adversaries to attack all rendezvous points just in case?

1 0

[torspec/master] tiny tweaks to proposal 255 after reading
by arma＠torproject.org 12 Feb '16

12 Feb '16

commit 0c14d27563e6cfb24ee2a11457f8b64b80512259 Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Feb 11 23:04:27 2016 -0500 tiny tweaks to proposal 255 after reading --- proposals/255-hs-load-balancing.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/255-hs-load-balancing.txt b/proposals/255-hs-load-balancing.txt index eaab035..a19949c 100644 --- a/proposals/255-hs-load-balancing.txt +++ b/proposals/255-hs-load-balancing.txt @@ -101,7 +101,7 @@ is the minimal amount of data required to process the INTRODUCE2 cell on another machine. Before proposal 224 is implemented, this could consist of the -INTRODUCE2 cell payload, the key to decrypt the cell with if the cell +INTRODUCE2 cell payload, the key to decrypt the cell if the cell is not already decrypted (which may be preferable, for performance reasons), and data necessary for other machines to recognize what to do with the cell. @@ -136,7 +136,7 @@ INTRODUCE2 cell arrives at the node which published the descriptor, it does not immediately try to perform the rendezvous, but instead outputs this to the controller. Through an out-of-band process this message is relayed to a controller of another node of Bob's, and this transmits -the "PERFORM-RENDEZVOUS" command to that node. This node finally +the "PERFORM-RENDEZVOUS" command to that node. This node performs the rendezvous, and will continue to serve data to Alice, whose client will now not have to talk to the introduction point anymore. @@ -155,3 +155,4 @@ and to leave the actual load-balancing algorithm to the implementor of the controller. The developer of the tor implementation should not have to choose between a round-robin algorithm and something that could pull CPU load averages from a centralized monitoring system. +

1 0

[tor/master] Fix all doxygen warnings other than "X is not documented"
by nickm＠torproject.org 12 Feb '16

12 Feb '16

commit 1f679d4ae11cd976f5539bc4ddf36873132aeb00 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Feb 11 22:06:44 2016 -0500 Fix all doxygen warnings other than "X is not documented" --- src/or/config.c | 2 +- src/or/policies.c | 14 ++++++++------ src/or/routerparse.c | 2 +- 3 files changed, 10 insertions(+), 8 deletions(-) diff --git a/src/or/config.c b/src/or/config.c index d71cf6d..5273d5a 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -2693,7 +2693,7 @@ options_validate_cb(void *old_options, void *options, void *default_options, /** Log a warning message iff filepath is not absolute. * Warning message must contain option name option and - * an absolute path that filepath will resolve to. + * an absolute path that filepath will resolve to. * * In case filepath is absolute, do nothing. */ diff --git a/src/or/policies.c b/src/or/policies.c index 984ab6a..179230b 100644 --- a/src/or/policies.c +++ b/src/or/policies.c @@ -1703,19 +1703,21 @@ exit_policy_remove_redundancies(smartlist_t *dest) /** Reject private helper for policies_parse_exit_policy_internal: rejects * publicly routable addresses on this exit relay. * - * Add reject entries to the linked list *dest: - * - if configured_addresses is non-NULL, add entries that reject each - * tor_addr_t* in the list as a destination. - * - if reject_interface_addresses is true, add entries that reject each + * Add reject entries to the linked list *dest: + * <ul> + * <li>if configured_addresses is non-NULL, add entries that reject each + * tor_addr_t in the list as a destination. + * <li>if reject_interface_addresses is true, add entries that reject each * public IPv4 and IPv6 address of each interface on this machine. - * - if reject_configured_port_addresses is true, add entries that reject + * <li>if reject_configured_port_addresses is true, add entries that reject * each IPv4 and IPv6 address configured for a port. + * </ul> * * IPv6 entries are only added if ipv6_exit is true. (All IPv6 addresses are * already blocked by policies_parse_exit_policy_internal if ipv6_exit is * false.) * - * The list *dest is created as needed. + * The list in dest is created as needed. */ void policies_parse_exit_policy_reject_private( diff --git a/src/or/routerparse.c b/src/or/routerparse.c index fafba96..3be43dc 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3679,7 +3679,7 @@ networkstatus_parse_detached_signatures(const char *s, const char *eos) * * Returns NULL on policy errors. * - * Set *malformed_list>/b> to true if the entire policy list should be + * Set *malformed_list to true if the entire policy list should be * discarded. Otherwise, set it to false, and only this item should be ignored * on error - the rest of the policy list can continue to be processed and * used.

1 0

[translation/tails-openpgp-applet] Update translations for tails-openpgp-applet
by translation＠torproject.org 11 Feb '16

11 Feb '16

commit 2f815869be34ac66970989732b264e737d69803e Author: Translation commit bot <translation(a)torproject.org> Date: Thu Feb 11 18:46:49 2016 +0000 Update translations for tails-openpgp-applet --- eu/openpgp-applet.pot | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/eu/openpgp-applet.pot b/eu/openpgp-applet.pot index 6dedc2c..235e795 100644 --- a/eu/openpgp-applet.pot +++ b/eu/openpgp-applet.pot @@ -3,13 +3,14 @@ # This file is distributed under the same license as the PACKAGE package. # # Translators: +# Iban <iban.ferreira(a)gmail.com>, 2016 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: tails(a)boum.org\n" "POT-Creation-Date: 2015-08-10 15:55+0200\n" -"PO-Revision-Date: 2015-11-23 02:23+0000\n" -"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" +"PO-Revision-Date: 2016-02-11 18:28+0000\n" +"Last-Translator: Iban <iban.ferreira(a)gmail.com>\n" "Language-Team: Basque (http://www.transifex.com/otf/torproject/language/eu/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -92,8 +93,8 @@ msgstr "Hatz-marka:" #: bin/openpgp-applet:447 msgid "User ID:" msgid_plural "User IDs:" -msgstr[0] "" -msgstr[1] "" +msgstr[0] "Erabiltzaile ID:" +msgstr[1] "Erabiltzaile ID-ak:" #: bin/openpgp-applet:476 msgid "None (Don't sign)" @@ -128,8 +129,8 @@ msgstr "Gako hauetaz fidatzen zara?" #: bin/openpgp-applet:603 msgid "The following selected key is not fully trusted:" msgid_plural "The following selected keys are not fully trusted:" -msgstr[0] "" -msgstr[1] "" +msgstr[0] "Hurrengo gako aukeratua ez da guztiz fidagarria:" +msgstr[1] "Hurrengo gako aukeratuak ez dira guztiz fidagarriak:" #: bin/openpgp-applet:621 msgid "Do you trust this key enough to use it anyway?"

1 0

[translation/torbutton-aboutdialogdtd] Update translations for torbutton-aboutdialogdtd
by translation＠torproject.org 11 Feb '16

11 Feb '16

commit 719c203e1417a3b5a5e5be7ccd93c2649aa202ff Author: Translation commit bot <translation(a)torproject.org> Date: Thu Feb 11 18:46:05 2016 +0000 Update translations for torbutton-aboutdialogdtd --- tl_PH/aboutdialog.dtd | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/tl_PH/aboutdialog.dtd b/tl_PH/aboutdialog.dtd index 5099ad7..e957f74 100644 --- a/tl_PH/aboutdialog.dtd +++ b/tl_PH/aboutdialog.dtd @@ -1,19 +1,19 @@ -<!ENTITY project.start "&brandShortName; is developed by "> +<!ENTITY project.start "Ang &brandShortName; ay ginawa ng">  -<!ENTITY project.tpoLink "the &vendorShortName;"> +<!ENTITY project.tpoLink "&vendorShortName;"> <!ENTITY project.end ", a nonprofit working to defend your privacy and freedom online."> -<!ENTITY help.start "Want to help? "> +<!ENTITY help.start "Gusto mong Tumulong?">  -<!ENTITY help.donateLink "Donate"> -<!ENTITY help.or " or "> +<!ENTITY help.donateLink "Mag-donate"> +<!ENTITY help.or "o">  -<!ENTITY help.getInvolvedLink "get involved"> +<!ENTITY help.getInvolvedLink "makailahok"> <!ENTITY help.end "!">  -<!ENTITY bottomLinks.questions "Questions?"> +<!ENTITY bottomLinks.questions "Mga katanungan?">  -<!ENTITY bottomLinks.grow "Help the Tor Network Grow!"> +<!ENTITY bottomLinks.grow "Tulungang umnlad ang Tor Network!">  -<!ENTITY bottomLinks.license "Licensing Information"> -<!ENTITY tor.TrademarkStatement "'Tor' and the 'Onion Logo' are registered trademarks of the Tor Project, Inc."> +<!ENTITY bottomLinks.license "Kaalaman sa Paglisensiya"> +<!ENTITY tor.TrademarkStatement "Ang 'Tor' at ang 'Onion Logo' ay rehistradong pagmamay-ari ng Tor Project, Inc.">

1 0

[tor/master] Add an assertion to tor_libevent_get_base()
by nickm＠torproject.org 11 Feb '16

11 Feb '16

commit c595f6d25e9cda58f5327c5806e2c9a534c454f9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Feb 4 12:37:00 2016 -0500 Add an assertion to tor_libevent_get_base() Closes ticket 18241. --- changes/assert_event_base | 5 +++++ src/common/compat_libevent.c | 1 + 2 files changed, 6 insertions(+) diff --git a/changes/assert_event_base b/changes/assert_event_base new file mode 100644 index 0000000..b887795 --- /dev/null +++ b/changes/assert_event_base @@ -0,0 +1,5 @@ + o Minor features (robustness): + - Exit immediately with an error message if the code attempts to + use libevent without having initialized it. This should resolve + some frequently-made mistakes in our unit tests. Closes ticket + 18241. diff --git a/src/common/compat_libevent.c b/src/common/compat_libevent.c index 29e5c5f..c367ee4 100644 --- a/src/common/compat_libevent.c +++ b/src/common/compat_libevent.c @@ -247,6 +247,7 @@ tor_libevent_initialize(tor_libevent_cfg *torcfg) MOCK_IMPL(struct event_base *, tor_libevent_get_base, (void)) { + tor_assert(the_event_base != NULL); return the_event_base; }

1 0

[tor/master] Check that the log mutex is initialised before trying to lock or unlock it
by nickm＠torproject.org 11 Feb '16

11 Feb '16

commit db72b509d17311d289b140afb3456376c5525ad7 Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Feb 5 14:08:58 2016 +1100 Check that the log mutex is initialised before trying to lock or unlock it --- src/common/log.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/common/log.c b/src/common/log.c index 4a8a7b1..f71583f 100644 --- a/src/common/log.c +++ b/src/common/log.c @@ -149,10 +149,14 @@ static int pretty_fn_has_parens = 0; /** Lock the log_mutex to prevent others from changing the logfile_t list */ #define LOCK_LOGS() STMT_BEGIN \ + tor_assert(log_mutex_initialized); \ tor_mutex_acquire(&log_mutex); \ STMT_END /** Unlock the log_mutex */ -#define UNLOCK_LOGS() STMT_BEGIN tor_mutex_release(&log_mutex); STMT_END +#define UNLOCK_LOGS() STMT_BEGIN \ + tor_assert(log_mutex_initialized); \ + tor_mutex_release(&log_mutex); \ + STMT_END /** What's the lowest log level anybody cares about? Checking this lets us * bail out early from log_debug if we aren't debugging. */ @@ -482,6 +486,8 @@ logv,(int severity, log_domain_mask_t domain, const char *funcname, /* check that severity is sane. Overrunning the masks array leads to * interesting and hard to diagnose effects */ assert(severity >= LOG_ERR && severity <= LOG_DEBUG); + /* check that we've initialised the log mutex before we try to lock it */ + assert(log_mutex_initialized); LOCK_LOGS(); if ((! (domain & LD_NOCB)) && smartlist_len(pending_cb_messages))

1 0

[tor/master] Avoid calling log functions in logv when SMARTLIST_DEBUG is defined
by nickm＠torproject.org 11 Feb '16

11 Feb '16

commit add8acf42882a13af610ace6005d52544509a823 Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Feb 5 14:14:17 2016 +1100 Avoid calling log functions in logv when SMARTLIST_DEBUG is defined --- src/common/log.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/common/log.c b/src/common/log.c index f71583f..4779751 100644 --- a/src/common/log.c +++ b/src/common/log.c @@ -490,7 +490,8 @@ logv,(int severity, log_domain_mask_t domain, const char *funcname, assert(log_mutex_initialized); LOCK_LOGS(); - if ((! (domain & LD_NOCB)) && smartlist_len(pending_cb_messages)) + if ((! (domain & LD_NOCB)) && pending_cb_messages + && smartlist_len(pending_cb_messages)) flush_pending_log_callbacks(); if (queue_startup_messages && @@ -945,7 +946,7 @@ flush_pending_log_callbacks(void) smartlist_t *messages, *messages_tmp; LOCK_LOGS(); - if (0 == smartlist_len(pending_cb_messages)) { + if (!pending_cb_messages || 0 == smartlist_len(pending_cb_messages)) { UNLOCK_LOGS(); return; }

1 0

[tor/master] Initialise logging before trying to use it in unit tests
by nickm＠torproject.org 11 Feb '16

11 Feb '16

commit a7a98e27eadff634655a7845976adc7a23dcdc3f Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Feb 5 14:28:53 2016 +1100 Initialise logging before trying to use it in unit tests --- src/test/testing_common.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/test/testing_common.c b/src/test/testing_common.c index e20e9e6..fc4e05c 100644 --- a/src/test/testing_common.c +++ b/src/test/testing_common.c @@ -228,6 +228,9 @@ main(int c, const char **v) int loglevel = LOG_ERR; int accel_crypto = 0; + /* We must initialise logs before we call tor_assert() */ + init_logging(1); + #ifdef USE_DMALLOC { int r = CRYPTO_set_mem_ex_functions(tor_malloc_, tor_realloc_, tor_free_); @@ -239,7 +242,6 @@ main(int c, const char **v) options = options_new(); tor_threads_init(); control_initialize_event_queue(); - init_logging(1); configure_backtrace_handler(get_version()); for (i_out = i = 1; i < c; ++i) {

1 0