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

[translation/support-censorship_completed] Update translations for support-censorship_completed
by translation＠torproject.org 21 May '18

21 May '18

commit 5017ecbf85950b6b18d990ad132995e2b8e5623e Author: Translation commit bot <translation(a)torproject.org> Date: Mon May 21 15:48:54 2018 +0000 Update translations for support-censorship_completed --- pt_BR.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pt_BR.json b/pt_BR.json index 75c340dd5..ccd59fd81 100644 --- a/pt_BR.json +++ b/pt_BR.json @@ -9,7 +9,7 @@ "id": "#censura-2", "control": "censura-2", "title": "Meu website favorito está bloqueando o acesso via Tor.", - "description": "<p class=\"mb-3\"> Lamentamos saber que você não pode visitar o website que quer! Às vezes, os websites bloqueam os usuários do Tor porque não sabem a diferença entre o usuário médio e o tráfego automatizado. Uma estratégia na qual temos obtido sucesso para fazer os websites desbloquearem os usuários do Tor é fazer com que os próprios usuários contatem os administradores do site diretamente. Algo assim deve funcionar: <br /> \"Olá! Eu tentei acessar seu website xyz.com enquanto utilizando o Tor Browser e descobri que não há permissão de acesso para usuários do Tor. Eu peço que reconsiderem essa decisão; o Tor é utilizado por pessoas de todo o mundo que querem proteger sua privacidade e lutar contra a censura. Ao bloquear os usuários do Tor, vocês estão provavelmente bloqueando pessoas que querem usar uma internet livre em países opressores, jornalistas e pesquisadores que querem se proteger, ativistas e pessoas comuns que querem se livrar d o rastreamento de terceiros invasivos. Por favor, tomem uma posição forte em favor da privacidade digital e da liberdade na internet e permitam os usuários do Tor o acesso ao xyz.com. Obrigado.\" <br />No caso dos bancos, e outros sensitive websites, é também comum que apareçam bloqueios baseados na localização geográfica (se um banco sabe que você geralmente acessa seus serviços de um país, e de repente você está conectando de uma exit relay no outro lado do mundo, sua conta pode ser trancada ou suspensa). Se você não consegue se conectar a um onion service, por favor ver <a href=\"http://127.0.0.1:5000/#onionservices-3\">Não consigo acessar X.onion! </a> </p>" + "description": "<p class=\"mb-3\">Lamentamos saber que você não pôde visitar o website que gostaria! Às vezes, os websites bloqueiam pessoas que usam Tor porque não distinguem usuários normais do Tor e tráfego automatizado. Uma estratégia bem-sucedida para que os websites desbloqueiem usuários do Tor é fazer com que os próprios usuários contatem os administradores do site diretamente. Uma mensagem como esta deve funcionar:<br />\"Olá! Eu tentei acessar seu website xyz.com utilizando o Navegador Tor e descobri que não há permissão de acesso para usuários do Tor. Eu peço que vocês reconsiderem essa decisão, já que Tor é utilizado por pessoas de todo o mundo que querem proteger sua privacidade e lutar contra a censura. Ao bloquear as pessoas que usam Tor, vocês provavelmente estão bloqueando pessoas que querem usar uma internet livre em países opressores, jornalistas e pesquisadores que querem se proteger, assim como ativistas e pessoas comuns que querem se li vrar do rastreamento de agentes invasivos. Por favor, tomem uma posição forte em favor da privacidade digital e da liberdade na internet e permitam o acesso ao xyz.com às pessoas que usam Tor. Agradeço a sua atenção.\"<br />No caso de bancos e outros sites delicados, bloqueios baseados na localização geográfica são comuns (se um banco souber que você geralmente acessa seus serviços em um certo país e de repente você se conecta a partir de um retransmissor de saída do Tor localizado em um outro país, sua conta pode ser bloqueada ou suspensa). Se você não conseguir se conectar a um serviço onion, por favor, consulte<a href=\"#onionservices-3\">Não consigo acessar X.onion!</a></p>" }, "censorship-3": { "id": "#censura-3", @@ -27,7 +27,7 @@ "id": "#censura-5", "control": "censura-5", "title": "Estou tendo problemas para conectar ao Tor e não consigo descobrir o que está dando errado.", - "description": "<p class=\"mb-3\">Se estiver tendo problemas ao se conectar, por favor selecione a opção para \"copiar o log de Tor para a área de transferências\". Em seguida cole o log do Tor em um arquivo de texto ou outro documento. Você deverá ver um destes erros de logs comuns (procure as seguintes linhas no seu log do Tor):<h5>Erro de log comum #1: Falha na conexão de Proxy</h5><p class=\"mb-3\"><pre>2017-10-29 09:23:40.800 [OBSERVE] Opening Socks listener on 127.0.0.1:9150\n2017-10-29 09:23:47.900 [OBSERVE] Bootstrapped 5%: Conectando ao servidor do diretório\n2017-10-29 09:23:47.900 [OBSERVE] Bootstrapped 10%: Concluindo o 'handshake' com o servidor do diretório\n2017-10-29 09:24:08.900 [AVISO] Cliente: de Proxy: não foi possível conectar-se à xx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\")\n2017-10-29 09:24:08.900 [AVISO] Cliente: de Proxy: não foi possível conectar-se à xx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\")\n2017-10-29 09:24:0 8.900 [AVISO] Cliente: de Proxy: não foi possível conectar-se à xx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\") Se você encontrar linhas como estas em seu log do Tor, isto significa que falhou em conectar-se à um SOCKS proxy. Se um SOCKS proxy é obrigatório para a sua configuração de rede, por favor certifique-se que você digitou seus detalhes de proxy corretamente. Se um SOCKS proxy não é obrigatório, ou você não está certo sobre isso, por favor tente conectar-se à rede Tor sem um SOCKS proxy. Erro de log comum #2: Can’t reach guard relays 11/1/2017 21:11:43 PM.500 [OBSERVE] Opening Socks listener on 127.0.0.1:9150\n11/1/2017 21:11:44 PM.300 [OBSERVE] Bootstrapped 80%: Conectando à rede Tor\n11/1/2017 21:11:44 PM.300 [AVISO] Failed to find node for hop 0 of our path. Discarding this circuit.\n11/1/2017 21:11:44 PM.500 [OBSERVE] Bootstrapped 85%: Finishing handshake with first hop\n11/1/2017 21:11:45 PM.300 [AVISO] Failed to find node for hop 0 of our path. Discarding this circuit.If you see lines like these in your Tor log, it means your Tor failed to connect to the first node in the Tor circuit. This could mean that you’re on a network that’s censored. Please try connecting with bridges, and that should fix the problem.Common log error #3: Failed to complete TLS handshake 13-11-17 19:52:24.300 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server\n13-11-17 19:53:49.300 [WARN] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 10; recommendation warn; host [host] at xxx.xxx.xxx.xx:xxx)\n13-11-17 19:53:49.300 [WARN] 10 connections have failed:\n13-11-17 19:53:49.300 [WARN] 9 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE\n13-11-17 19:53:49.300 [WARN] 1 connections died in state connect()ing with SSL state (No SSL object)If you see lines like this in your Tor log, it means that Tor failed to complete a TLS hands hake with the directory authorities. Using bridges will likely fix this.Common log error #4: Clock skew 19.11.2017 00:04:47.400 [NOTICE] Opening Socks listener on 127.0.0.1:9150\n19.11.2017 00:04:48.000 [NOTICE] Bootstrapped 5%: Connecting to directory server\n19.11.2017 00:04:48.200 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server\n19.11.2017 00:04:48.800 [WARN] Received NETINFO cell with skewed time (OR:xxx.xx.x.xx:xxxx): It seems that our clock is behind by 1 days, 0 hours, 1 minutes, or that theirs is ahead.\nTor requires an accurate clock to work: please check your time, timezone, and date settings.If you see lines like this in your Tor log, it means your system clock is incorrect. Please make sure your clock is set accurately, including the correct timezone. Then restart Tor. " + "description": "<p class=\"mb-3\">Se você estiver tendo dificuldades para se conectar, por favor selecione a opção \"copiar o log do Tor na área de trabalho\". Em seguida, copie o log to Tor em um arquivo de texto ou outro documento. Normalmente você verá um dos erros mais comuns (procure as seguintes linhas no seu log do Tor):</p><h5>Erros comuns #1: falha de conexão com o Proxy</h5><p class=\"mb-3\"><pre><code> 2017-10-29 09:23:40.800 [NOTICE] Opening Socks listener on 127.0.0.1:9150 \n 2017-10-29 09:23:47.900 [NOTICE] Bootstrapped 5%: Connecting to directory server \n 2017-10-29 09:23:47.900 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server \n 2017-10-29 09:24:08.900 [WARN] Proxy Client: unable to connect to xx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\") \n 2017-10-29 09:24:08.900 [WARN] Proxy Client: unable to connect to xx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\") \n 2017-10-29 09:24:08.900 [WARN] Proxy Client: unable to connect toxx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\")</code></pre></p><p class=\"mb-3\">Se você vir mensagens como essas no seu log do Tor, é porque você nao esta se conectando a nenhum proxy SOCKS. Se um proxy SOCKS for necessário para configurar a sua rede, por favor, verifique se você inseriu os detalhes do proxy corretamente. If a SOCKS proxy is not required, or you’re not sure, please try connecting to the Tor network without a SOCKS proxy.<p><h5>Common log error #2: Can’t reach guard relays</h5><p class=\"mb-3\"><pre><code> 11/1/2017 21:11:43 PM.500 [NOTICE] Opening Socks listener on 127.0.0.1:9150 \n 11/1/2017 21:11:44 PM.300 [NOTICE] Bootstrapped 80%: Connecting to the Tor network \n 11/1/2017 21:11:44 PM.300 [WARN] Failed to find node for hop 0 of our path. Discarding this circuit. \n 11/1/2017 21:11:44 PM.500 [NOTICE] Bootstrapped 85%: Finishing handshake with first hop \n 11/1/2017 21:11:45 PM.300 [WARN] Failed to find node for hop 0 of our path. Discardi ng this circuit.</code></pre></p><p class=\"mb-3\">If you see lines like these in your Tor log, it means your Tor failed to connect to the first node in the Tor circuit. This could mean that you’re on a network that’s censored. Please try connecting with bridges, and that should fix the problem.</p><h5>Common log error #3: Failed to complete TLS handshake</h5><p class=\"mb-3\"><pre><code> 13-11-17 19:52:24.300 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server \n 13-11-17 19:53:49.300 [WARN] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 10; recommendation warn; host [host] at xxx.xxx.xxx.xx:xxx) \n 13-11-17 19:53:49.300 [WARN] 10 connections have failed: \n 13-11-17 19:53:49.300 [WARN] 9 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE \n 13-11-17 19:53:49.300 [WARN] 1 connections died in state connect()ing with SSL state (No SSL object)</code></pre></p><p class=\"mb-3\">If you see lines like this in your Tor log, it means that Tor failed to complete a TLS handshake with the directory authorities. Using bridges will likely fix this.</p><h5>Common log error #4: Clock skew</h5><p class=\"mb-3\"><pre><code> 19.11.2017 00:04:47.400 [NOTICE] Opening Socks listener on 127.0.0.1:9150 \n 19.11.2017 00:04:48.000 [NOTICE] Bootstrapped 5%: Connecting to directory server \n 19.11.2017 00:04:48.200 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server \n 19.11.2017 00:04:48.800 [WARN] Received NETINFO cell with skewed time (OR:xxx.xx.x.xx:xxxx): It seems that our clock is behind by 1 days, 0 hours, 1 minutes, or that theirs is ahead. \n Tor requires an accurate clock to work: please check your time, timezone, and date settings.</code></pre></p><p class=\"mb-3\">If you see lines like this in your Tor log, it means your system clock is incorrect. Please make sure your clock is set accurately, including the correct timezone. Then rest art Tor. </p>" }, "censorship-6": { "id": "#censura-6",

1 0

[translation/support-censorship] Update translations for support-censorship
by translation＠torproject.org 21 May '18

21 May '18

commit 88b51f5c1df247156c442c57c23efb27a584b693 Author: Translation commit bot <translation(a)torproject.org> Date: Mon May 21 15:48:49 2018 +0000 Update translations for support-censorship --- pt_BR.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pt_BR.json b/pt_BR.json index 46257eec1..ccd59fd81 100644 --- a/pt_BR.json +++ b/pt_BR.json @@ -27,7 +27,7 @@ "id": "#censura-5", "control": "censura-5", "title": "Estou tendo problemas para conectar ao Tor e não consigo descobrir o que está dando errado.", - "description": "<p class=\"mb-3\">If you’re having trouble connecting, please select the option to \"copy Tor log to clipboard.\" Then paste the Tor log into a text file or other document. You should see one of these common log errors (look for the following lines in your Tor log):</p><h5>Common log error #1: Proxy connection failure</h5><p class=\"mb-3\"><pre><code> 2017-10-29 09:23:40.800 [NOTICE] Opening Socks listener on 127.0.0.1:9150 \n 2017-10-29 09:23:47.900 [NOTICE] Bootstrapped 5%: Connecting to directory server \n 2017-10-29 09:23:47.900 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server \n 2017-10-29 09:24:08.900 [WARN] Proxy Client: unable to connect to xx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\") \n 2017-10-29 09:24:08.900 [WARN] Proxy Client: unable to connect to xx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\") \n 2017-10-29 09:24:08.900 [WARN] Proxy Client: unable to connect toxx..xxx..xxx.xx:xxxxx (\"general SOCKS server fa ilure\")</code></pre></p><p class=\"mb-3\">If you see lines like these in your Tor log, it means you are failing to connect to a SOCKS proxy. If a SOCKS proxy is required for your network setup, then please make sure you’ve entered your proxy details correctly. If a SOCKS proxy is not required, or you’re not sure, please try connecting to the Tor network without a SOCKS proxy.<p><h5>Common log error #2: Can’t reach guard relays</h5><p class=\"mb-3\"><pre><code> 11/1/2017 21:11:43 PM.500 [NOTICE] Opening Socks listener on 127.0.0.1:9150 \n 11/1/2017 21:11:44 PM.300 [NOTICE] Bootstrapped 80%: Connecting to the Tor network \n 11/1/2017 21:11:44 PM.300 [WARN] Failed to find node for hop 0 of our path. Discarding this circuit. \n 11/1/2017 21:11:44 PM.500 [NOTICE] Bootstrapped 85%: Finishing handshake with first hop \n 11/1/2017 21:11:45 PM.300 [WARN] Failed to find node for hop 0 of our path. Discarding this circuit.</code></pre></p><p class=\"mb-3\">If you see lines like these in your Tor log, it means your Tor failed to connect to the first node in the Tor circuit. This could mean that you’re on a network that’s censored. Please try connecting with bridges, and that should fix the problem.</p><h5>Common log error #3: Failed to complete TLS handshake</h5><p class=\"mb-3\"><pre><code> 13-11-17 19:52:24.300 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server \n 13-11-17 19:53:49.300 [WARN] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 10; recommendation warn; host [host] at xxx.xxx.xxx.xx:xxx) \n 13-11-17 19:53:49.300 [WARN] 10 connections have failed: \n 13-11-17 19:53:49.300 [WARN] 9 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE \n 13-11-17 19:53:49.300 [WARN] 1 connections died in state connect()ing with SSL state (No SSL object)</code></pre></p><p class=\"mb-3\">If you see lines like this in your Tor log, it means that Tor failed to complete a TLS handshake with the directory authorities. Using bridges will likely fix this.</p><h5>Common log error #4: Clock skew</h5><p class=\"mb-3\"><pre><code> 19.11.2017 00:04:47.400 [NOTICE] Opening Socks listener on 127.0.0.1:9150 \n 19.11.2017 00:04:48.000 [NOTICE] Bootstrapped 5%: Connecting to directory server \n 19.11.2017 00:04:48.200 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server \n 19.11.2017 00:04:48.800 [WARN] Received NETINFO cell with skewed time (OR:xxx.xx.x.xx:xxxx): It seems that our clock is behind by 1 days, 0 hours, 1 minutes, or that theirs is ahead. \n Tor requires an accurate clock to work: please check your time, timezone, and date settings.</code></pre></p><p class=\"mb-3\">If you see lines like this in your Tor log, it means your system clock is incorrect. Please make sure your clock is set accurately, including the correct timezone. Then restart Tor. </p>" + "description": "<p class=\"mb-3\">Se você estiver tendo dificuldades para se conectar, por favor selecione a opção \"copiar o log do Tor na área de trabalho\". Em seguida, copie o log to Tor em um arquivo de texto ou outro documento. Normalmente você verá um dos erros mais comuns (procure as seguintes linhas no seu log do Tor):</p><h5>Erros comuns #1: falha de conexão com o Proxy</h5><p class=\"mb-3\"><pre><code> 2017-10-29 09:23:40.800 [NOTICE] Opening Socks listener on 127.0.0.1:9150 \n 2017-10-29 09:23:47.900 [NOTICE] Bootstrapped 5%: Connecting to directory server \n 2017-10-29 09:23:47.900 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server \n 2017-10-29 09:24:08.900 [WARN] Proxy Client: unable to connect to xx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\") \n 2017-10-29 09:24:08.900 [WARN] Proxy Client: unable to connect to xx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\") \n 2017-10-29 09:24:08.900 [WARN] Proxy Client: unable to connect toxx..xxx..xxx.xx:xxxxx (\"general SOCKS server failure\")</code></pre></p><p class=\"mb-3\">Se você vir mensagens como essas no seu log do Tor, é porque você nao esta se conectando a nenhum proxy SOCKS. Se um proxy SOCKS for necessário para configurar a sua rede, por favor, verifique se você inseriu os detalhes do proxy corretamente. If a SOCKS proxy is not required, or you’re not sure, please try connecting to the Tor network without a SOCKS proxy.<p><h5>Common log error #2: Can’t reach guard relays</h5><p class=\"mb-3\"><pre><code> 11/1/2017 21:11:43 PM.500 [NOTICE] Opening Socks listener on 127.0.0.1:9150 \n 11/1/2017 21:11:44 PM.300 [NOTICE] Bootstrapped 80%: Connecting to the Tor network \n 11/1/2017 21:11:44 PM.300 [WARN] Failed to find node for hop 0 of our path. Discarding this circuit. \n 11/1/2017 21:11:44 PM.500 [NOTICE] Bootstrapped 85%: Finishing handshake with first hop \n 11/1/2017 21:11:45 PM.300 [WARN] Failed to find node for hop 0 of our path. Discardi ng this circuit.</code></pre></p><p class=\"mb-3\">If you see lines like these in your Tor log, it means your Tor failed to connect to the first node in the Tor circuit. This could mean that you’re on a network that’s censored. Please try connecting with bridges, and that should fix the problem.</p><h5>Common log error #3: Failed to complete TLS handshake</h5><p class=\"mb-3\"><pre><code> 13-11-17 19:52:24.300 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server \n 13-11-17 19:53:49.300 [WARN] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 10; recommendation warn; host [host] at xxx.xxx.xxx.xx:xxx) \n 13-11-17 19:53:49.300 [WARN] 10 connections have failed: \n 13-11-17 19:53:49.300 [WARN] 9 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE \n 13-11-17 19:53:49.300 [WARN] 1 connections died in state connect()ing with SSL state (No SSL object)</code></pre></p><p class=\"mb-3\">If you see lines like this in your Tor log, it means that Tor failed to complete a TLS handshake with the directory authorities. Using bridges will likely fix this.</p><h5>Common log error #4: Clock skew</h5><p class=\"mb-3\"><pre><code> 19.11.2017 00:04:47.400 [NOTICE] Opening Socks listener on 127.0.0.1:9150 \n 19.11.2017 00:04:48.000 [NOTICE] Bootstrapped 5%: Connecting to directory server \n 19.11.2017 00:04:48.200 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server \n 19.11.2017 00:04:48.800 [WARN] Received NETINFO cell with skewed time (OR:xxx.xx.x.xx:xxxx): It seems that our clock is behind by 1 days, 0 hours, 1 minutes, or that theirs is ahead. \n Tor requires an accurate clock to work: please check your time, timezone, and date settings.</code></pre></p><p class=\"mb-3\">If you see lines like this in your Tor log, it means your system clock is incorrect. Please make sure your clock is set accurately, including the correct timezone. Then rest art Tor. </p>" }, "censorship-6": { "id": "#censura-6",

1 0

[translation/support-tormessenger] Update translations for support-tormessenger
by translation＠torproject.org 21 May '18

21 May '18

commit 20b700ee28b8f4251cb9dcc309bd998dc5e8b311 Author: Translation commit bot <translation(a)torproject.org> Date: Mon May 21 15:19:47 2018 +0000 Update translations for support-tormessenger --- pt_BR.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pt_BR.json b/pt_BR.json index 7546ea4c7..5795830a1 100644 --- a/pt_BR.json +++ b/pt_BR.json @@ -8,7 +8,7 @@ "messenger-2": { "id": "#messenger-2", "control": "messenger-2", - "title": "What platforms is Tor Messenger available on?", + "title": "Em quais plataformas Tor Messenger é disponível?", "description": "<p class=\"mb-3\">Tor Messenger (beta) é atualmente disponível para Linux, Windows, and macOS (OS X).</p>" }, "messenger-3": {

1 0

[tor/release-0.3.3] Write a blurb for 0.3.3.6
by nickm＠torproject.org 21 May '18

21 May '18

commit f15e1e65cbd7a20844f6375b0f0eececd6996516 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon May 21 09:28:00 2018 -0400 Write a blurb for 0.3.3.6 --- ChangeLog | 11 ++++++++++- ReleaseNotes | 11 ++++++++++- 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 2314abdfe..5473a3288 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,14 @@ Changes in version 0.3.3.6 - 2018-05-?? - BLURB + Tor 0.3.3.6 is the first stable release in the 0.3.3 series. It + backports several important fixes from the 0.3.4.1-alpha. + + The Tor 0.3.3 series includes several important features, including + improved denial-of-service resistance, controller support and other + improvements for v3 onion services, and official support for embedding + Tor within other applications. It also include our first non-trivial + module written in the Rust programming language. (Rust is still not + enabled by default when building Tor.) And as usual, there are + numerous other smaller bugfixes, features, and improvements. Below are the changes since 0.3.3.5-rc. For a list of all changes since 0.3.2, see the ReleaseNotes file. diff --git a/ReleaseNotes b/ReleaseNotes index ba9621421..1772288f2 100644 --- a/ReleaseNotes +++ b/ReleaseNotes @@ -3,7 +3,16 @@ of Tor. If you want to see more detailed descriptions of the changes in each development snapshot, see the ChangeLog file. Changes in version 0.3.3.6 - 2018-05-?? - BLURB + Tor 0.3.3.6 is the first stable release in the 0.3.3 series. It + backports several important fixes from the 0.3.4.1-alpha. + + The Tor 0.3.3 series includes several important features, including + improved denial-of-service resistance, controller support and other + improvements for v3 onion services, and official support for embedding + Tor within other applications. It also include our first non-trivial + module written in the Rust programming language. (Rust is still not + enabled by default when building Tor.) And as usual, there are + numerous other smaller bugfixes, features, and improvements. Below are the changes since the 0.3.2 series. For a list of only the changes since 0.3.3.5-rc, see the ChangeLog file.

1 0

[tor/release-0.3.3] 033 releasenotes: minor sorting
by nickm＠torproject.org 21 May '18

21 May '18

commit 7760162b8cf7d7a66b2e7416618d30876654568f Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon May 21 09:16:28 2018 -0400 033 releasenotes: minor sorting --- ReleaseNotes | 108 +++++++++++++++++++++++++---------------------------------- 1 file changed, 46 insertions(+), 62 deletions(-) diff --git a/ReleaseNotes b/ReleaseNotes index be177d31f..ba9621421 100644 --- a/ReleaseNotes +++ b/ReleaseNotes @@ -65,6 +65,12 @@ Changes in version 0.3.3.6 - 2018-05-?? hop. These options are for use in conjunction with experiments with "vanguards" for preventing guard enumeration attacks. Closes ticket 13837. + - When v3 onion service clients send introduce cells, they now + include the IPv6 address of the rendezvous point, if it has one. + Current v3 onion services running 0.3.2 ignore IPv6 addresses, but + in future Tor versions, IPv6-only v3 single onion services will be + able to use IPv6 addresses to connect directly to the rendezvous + point. Closes ticket 23577. Patch by Neel Chauhan. o Major features (rust, portability, experimental): - Tor now ships with an optional implementation of one of its @@ -81,14 +87,6 @@ Changes in version 0.3.3.6 - 2018-05-?? the storage location for relay's keys can be overridden with the KeyDirectory option. Closes ticket 22703. - o Major features (v3 onion services, ipv6): - - When v3 onion service clients send introduce cells, they now - include the IPv6 address of the rendezvous point, if it has one. - Current v3 onion services running 0.3.2 ignore IPv6 addresses, but - in future Tor versions, IPv6-only v3 single onion services will be - able to use IPv6 addresses to connect directly to the rendezvous - point. Closes ticket 23577. Patch by Neel Chauhan. - o Major bugfixes (directory authorities, security, backport from 0.3.4.1-alpha): - When directory authorities read a zero-byte bandwidth file, they would previously log a warning with the contents of an @@ -143,17 +141,11 @@ Changes in version 0.3.3.6 - 2018-05-?? - Add Link protocol version 5 to the supported protocols list. Fixes bug 25070; bugfix on 0.3.1.1-alpha. - o Major bugfixes (relay, connection): + o Major bugfixes (relay): - If we have failed to connect to a relay and received a connection refused, timeout, or similar error (at the TCP level), do not try that same address/port again for 60 seconds after the failure has occurred. Fixes bug 24767; bugfix on 0.0.6. - - o Major bugfixes (relay, denial of service, backport from 0.3.4.1-alpha): - - Impose a limit on circuit cell queue size. The limit can be controlled by - a consensus parameter. Fixes bug 25226; bugfix on 0.2.4.14-alpha. - - o Major bugfixes (relays): - Fix a set of false positives where relays would consider connections to other relays as being client-only connections (and thus e.g. deserving different link padding schemes) if those @@ -161,23 +153,15 @@ Changes in version 0.3.3.6 - 2018-05-?? initial handshake and whether the connection authenticated as a relay. Fixes bug 24898; bugfix on 0.3.1.1-alpha. + o Major bugfixes (relay, denial of service, backport from 0.3.4.1-alpha): + - Impose a limit on circuit cell queue size. The limit can be controlled by + a consensus parameter. Fixes bug 25226; bugfix on 0.2.4.14-alpha. + o Major bugfixes (scheduler, consensus): - The scheduler subsystem was failing to promptly notice changes in consensus parameters, making it harder to switch schedulers network-wide. Fixes bug 24975; bugfix on 0.3.2.1-alpha. - o Minor feature (continuous integration): - - Update the Travis CI configuration to use the stable Rust channel, - now that we have decided to require that. Closes ticket 25714. - - o Minor feature (IPv6): - - Make IPv6-only clients wait for microdescs for relays, even if we - were previously using descriptors (or were using them as a bridge) - and have a cached descriptor for them. Implements 23827. - - When a consensus has IPv6 ORPorts, make IPv6-only clients use - them, rather than waiting to download microdescriptors. - Implements 23827. - o Minor features (cleanup): - Tor now deletes the CookieAuthFile and ExtORPortCookieAuthFile when it stops. Closes ticket 23271. @@ -199,6 +183,10 @@ Changes in version 0.3.3.6 - 2018-05-?? more. Otherwise we use the former value of 75%. Closes ticket 24782. + o Minor features (continuous integration): + - Update the Travis CI configuration to use the stable Rust channel, + now that we have decided to require that. Closes ticket 25714. + o Minor features (continuous integration, backport from 0.3.4.1-alpha): - Our .travis.yml configuration now includes support for testing the results of "make distcheck". (It's not uncommon for "make check" to @@ -296,12 +284,6 @@ Changes in version 0.3.3.6 - 2018-05-?? o Minor features (geoip): - Update geoip and geoip6 to the May 1 2018 Maxmind GeoLite2 Country database. Closes ticket 26104. - - Update geoip and geoip6 to the April 3 2018 Maxmind GeoLite2 - Country database. Closes ticket 25718. - - Update geoip and geoip6 to the March 8 2018 Maxmind GeoLite2 - Country database. Closes ticket 25469. - - Update geoip and geoip6 to the February 7 2018 Maxmind GeoLite2 - Country database. o Minor features (heartbeat): - Add onion service information to our heartbeat logs, displaying @@ -314,6 +296,14 @@ Changes in version 0.3.3.6 - 2018-05-?? heartbeat messages. We hope to use this to improve Tor's behavior when it's trying to sleep. Closes ticket 24605. + o Minor features (IPv6): + - Make IPv6-only clients wait for microdescs for relays, even if we + were previously using descriptors (or were using them as a bridge) + and have a cached descriptor for them. Implements 23827. + - When a consensus has IPv6 ORPorts, make IPv6-only clients use + them, rather than waiting to download microdescriptors. + Implements 23827. + o Minor features (log messages): - Improve log message in the out-of-memory handler to include information about memory usage from the different compression @@ -326,12 +316,8 @@ Changes in version 0.3.3.6 - 2018-05-?? o Minor features (logging): - Clarify the log messages produced when getrandom() or a related entropy-generation mechanism gives an error. Closes ticket 25120. - - o Minor features (logging, android): - Added support for the Android logging subsystem. Closes ticket 24362. - - o Minor features (logging, diagnostic): - When logging a failure to create an onion service's descriptor, also log what the problem with the descriptor was. Diagnostic for ticket 24972. @@ -388,28 +374,6 @@ Changes in version 0.3.3.6 - 2018-05-?? really meant for developers only. It will likely be removed in a future release. Implements ticket 24583. - o Minor bugfix (channel connection): - - Use the actual observed address of an incoming relay connection, - not the canonical address of the relay from its descriptor, when - making decisions about how to handle the incoming connection. - Fixes bug 24952; bugfix on 0.2.4.11-alpha. Patch by "ffmancera". - - o Minor bugfix (directory authority): - - Directory authorities, when refusing a descriptor from a rejected - relay, now explicitly tell the relay (in its logs) to set a valid - ContactInfo address and contact the bad-relays@ mailing list. - Fixes bug 25170; bugfix on 0.2.9.1. - - o Minor bugfix (network IPv6 test): - - Tor's test scripts now check if "ping -6 ::1" works when the user - runs "make test-network-all". Fixes bug 24677; bugfix on - 0.2.9.3-alpha. Patch by "ffmancera". - - o Minor bugfixes (all versions of Tor): - - Use the "misspell" tool to detect and fix typos throughout the - source code. Fixes bug 23650; bugfix on various versions of Tor. - Patch from Deepesh Pathak. - o Minor bugfixes (build, rust): - Fix output of autoconf checks to display success messages for Rust dependencies and a suitable rustc compiler version. Fixes bug @@ -429,6 +393,12 @@ Changes in version 0.3.3.6 - 2018-05-?? dereference. Fixes bug 25629; bugfix on 0.2.9.15. Found by Coverity; this is CID 1430932. + o Minor bugfixes (channel connection): + - Use the actual observed address of an incoming relay connection, + not the canonical address of the relay from its descriptor, when + making decisions about how to handle the incoming connection. + Fixes bug 24952; bugfix on 0.2.4.11-alpha. Patch by "ffmancera". + o Minor bugfixes (channel, client): - Better identify client connection when reporting to the geoip client cache. Fixes bug 24904; bugfix on 0.3.1.7. @@ -453,8 +423,6 @@ Changes in version 0.3.3.6 - 2018-05-?? - Restore the correct operation of the RESOLVE command, which had been broken since we added the ability to enable/disable DNS on specific listener ports. Fixes bug 25617; bugfix on 0.2.9.3-alpha. - - o Minor bugfixes (controller, reliability): - Avoid a (nonfatal) assertion failure when extending a one-hop circuit from the controller to become a multihop circuit. Fixes bug 24903; bugfix on 0.2.5.2-alpha. @@ -484,6 +452,12 @@ Changes in version 0.3.3.6 - 2018-05-?? explicitly initialize the port to zero. Fixes bug 24488; bugfix on 0.2.4.1-alpha. + o Minor bugfixes (directory authority): + - Directory authorities, when refusing a descriptor from a rejected + relay, now explicitly tell the relay (in its logs) to set a valid + ContactInfo address and contact the bad-relays@ mailing list. + Fixes bug 25170; bugfix on 0.2.9.1. + o Minor bugfixes (documentation): - Document that the PerConnBW{Rate,Burst} options will fall back to their corresponding consensus parameters only if those parameters @@ -530,7 +504,7 @@ Changes in version 0.3.3.6 - 2018-05-?? router descriptors when updating addresses for a bridge. Closes ticket 24572; bugfix on 0.2.4.5-alpha. Patch by "ffmancera". - o Minor bugfixes (linux seccomp2 sandbox): + o Minor bugfixes (Linux seccomp2 sandbox): - When running with the sandbox enabled, reload configuration files correctly even when %include was used. Previously we would crash. Fixes bug 22605; bugfix on 0.3.1. Patch from Daniel Pinto. @@ -560,6 +534,11 @@ Changes in version 0.3.3.6 - 2018-05-?? - Fix a harmless memory leak in tor-resolve. Fixes bug 24582; bugfix on 0.2.1.1-alpha. + o Minor bugfixes (network IPv6 test): + - Tor's test scripts now check if "ping -6 ::1" works when the user + runs "make test-network-all". Fixes bug 24677; bugfix on + 0.2.9.3-alpha. Patch by "ffmancera". + o Minor bugfixes (networking): - Tor will no longer reject IPv6 address strings from TorBrowser when they are passed as hostnames in SOCKS5 requests. Fixes bug @@ -651,6 +630,11 @@ Changes in version 0.3.3.6 - 2018-05-?? - Forbid UINT32_MAX as a protocol version. Fixes part of bug 25249; bugfix on 0.2.9.4-alpha. + o Minor bugfixes (spelling): + - Use the "misspell" tool to detect and fix typos throughout the + source code. Fixes bug 23650; bugfix on various versions of Tor. + Patch from Deepesh Pathak. + o Minor bugfixes (testing): - Avoid intermittent test failures due to a test that had relied on onion service introduction point creation finishing within 5

1 0

[stem/master] Refactor dropping uncacheable GETCONF params into _set_cache()
by atagar＠torproject.org 21 May '18

21 May '18

commit 9e517998c59a437e7050ebfb685066d249abb21e Author: Dave Rolek <dmr-x(a)riseup.net> Date: Mon May 14 04:14:19 2018 +0000 Refactor dropping uncacheable GETCONF params into _set_cache() This likely also fixes a bug where _set_cache() was called without dropping these first. See #25821 --- stem/control.py | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/stem/control.py b/stem/control.py index c045eba4..c2467a53 100644 --- a/stem/control.py +++ b/stem/control.py @@ -2229,10 +2229,6 @@ class Controller(BaseController): if self.is_caching_enabled(): to_cache = dict((k.lower(), v) for k, v in response.entries.items()) - for key in UNCACHEABLE_GETCONF_PARAMS: - if key in to_cache: - del to_cache[key] - self._set_cache(to_cache, 'getconf') # Maps the entries back to the parameters that the user requested so the @@ -3190,6 +3186,14 @@ class Controller(BaseController): return + # remove uncacheable items + if namespace == 'getconf': + # shallow copy before edit so as not to change it for the caller + params = params.copy() + for key in UNCACHEABLE_GETCONF_PARAMS: + if key in params: + del params[key] + for key, value in list(params.items()): if namespace: cache_key = '%s.%s' % (namespace, key)

1 0

[stem/master] Refactor cache invalidation resulting from config change into new method
by atagar＠torproject.org 21 May '18

21 May '18

commit fdd34f81b986fdb21e782993ca380d5e65036494 Author: Dave Rolek <dmr-x(a)riseup.net> Date: Mon May 14 16:20:49 2018 +0000 Refactor cache invalidation resulting from config change into new method into: _confchanged_cache_invalidation() Also use this for _confchanged_listener(), thereby likely fixing a few bugs from the additional cache invalidation beyond exit_policy. See #25821 --- stem/control.py | 41 ++++++++++++++++++++++++++++------------- 1 file changed, 28 insertions(+), 13 deletions(-) diff --git a/stem/control.py b/stem/control.py index c2467a53..b9534f31 100644 --- a/stem/control.py +++ b/stem/control.py @@ -1064,9 +1064,10 @@ class Controller(BaseController): def _confchanged_listener(event): if self.is_caching_enabled(): - self._set_cache(dict((k, None) for k in event.config), 'getconf') + to_cache = dict((k, None) for k in event.config) + self._set_cache(to_cache, 'getconf') - self._set_cache({'exit_policy': None}) # numerous options can change our policy + self._confchanged_cache_invalidation(to_cache) self.add_event_listener(_confchanged_listener, EventType.CONF_CHANGED) @@ -2435,18 +2436,8 @@ class Controller(BaseController): to_cache[param] = value - if 'hidden' in param: - self._set_cache({'hidden_service_conf': None}) - - # reset any getinfo parameters that can be changed by a SETCONF - - self._set_cache(dict([(k.lower(), None) for k in CACHEABLE_GETINFO_PARAMS_UNTIL_SETCONF]), 'getinfo') - self._set_cache(None, 'listeners') - self._set_cache(to_cache, 'getconf') - self._set_cache({'get_custom_options': None}) - - self._set_cache({'exit_policy': None}) # numerous options can change our policy + self._confchanged_cache_invalidation(dict(params)) else: log.debug('%s (failed, code: %s, message: %s)' % (query, response.code, response.message)) immutable_params = [k for k, v in params if stem.util.str_tools._to_unicode(k).lower() in IMMUTABLE_CONFIG_OPTIONS] @@ -3206,6 +3197,30 @@ class Controller(BaseController): else: self._request_cache[cache_key] = value + def _confchanged_cache_invalidation(self, params): + """ + Drops dependent portions of the cache when configuration changes. + + :param dict params: **dict** of 'config_key => value' pairs for configs + that changed. The entries' values are currently unused. + """ + + with self._cache_lock: + if not self.is_caching_enabled(): + return + + if any('hidden' in param.lower() for param in params.keys()): + self._set_cache({'hidden_service_conf': None}) + + # reset any getinfo parameters that can be changed by a SETCONF + + self._set_cache(dict([(k.lower(), None) for k in CACHEABLE_GETINFO_PARAMS_UNTIL_SETCONF]), 'getinfo') + self._set_cache(None, 'listeners') + + self._set_cache({'get_custom_options': None}) + + self._set_cache({'exit_policy': None}) # numerous options can change our policy + def is_caching_enabled(self): """ **True** if caching has been enabled, **False** otherwise.

1 0

[stem/master] Fix bug in cache invalidation for CONF_CHANGED
by atagar＠torproject.org 21 May '18

21 May '18

commit 17782bc44f9afbb7dea49085afad29a936b7a1a3 Author: Dave Rolek <dmr-x(a)riseup.net> Date: Mon May 14 18:51:18 2018 +0000 Fix bug in cache invalidation for CONF_CHANGED 'getconf' cache keys are normalized to lowercase See #25821 --- stem/control.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/stem/control.py b/stem/control.py index b9534f31..bd98f1bc 100644 --- a/stem/control.py +++ b/stem/control.py @@ -1064,7 +1064,7 @@ class Controller(BaseController): def _confchanged_listener(event): if self.is_caching_enabled(): - to_cache = dict((k, None) for k in event.config) + to_cache = dict((k.lower(), None) for k in event.config) self._set_cache(to_cache, 'getconf') self._confchanged_cache_invalidation(to_cache)

1 0

[stem/master] Changelog entry for configuration-changing cache improvements (#25821)
by atagar＠torproject.org 21 May '18

21 May '18

commit f03f001d4b412d597e766fae4734b863ce4c938d Author: Dave Rolek <dmr-x(a)riseup.net> Date: Thu May 17 15:52:20 2018 +0000 Changelog entry for configuration-changing cache improvements (#25821) --- docs/change_log.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/change_log.rst b/docs/change_log.rst index 0e60701b..257ff123 100644 --- a/docs/change_log.rst +++ b/docs/change_log.rst @@ -51,6 +51,7 @@ The following are only available within Stem's `git repository * Added a timeout argument to :class:`~stem.control.Controller` methods that could await a response (:trac:`26056`) * Stacktrace if :func:`stem.connection.connect` had a string port argument * More reliable ExitPolicy resolution (:trac:`25739`) + * More reliable caching during configuration changes, especially in multiple-controller situations (:trac:`25821`) * Added the delivered_read, delivered_written, overhead_read, and overhead_written attributes to :class:`~stem.response.events.CircuitBandwidthEvent` (:spec:`fbb38ec`) * The *config* attribute of :class:`~stem.response.events.ConfChangedEvent` couldn't represent tor configuration options with multiple values. It has been replaced with new *changed* and *unset* attributes. * Replaced socket's :func:`~stem.socket.ControlPort.get_address`, :func:`~stem.socket.ControlPort.get_port`, and :func:`~stem.socket.ControlSocketFile.get_socket_path` with attributes

1 0

[stem/master] Drop cache values for set_options() params instead of setting cache
by atagar＠torproject.org 21 May '18

21 May '18

commit 1eb527579d83ac6d2bc5c15eceeaabe0fa5f927b Author: Dave Rolek <dmr-x(a)riseup.net> Date: Tue May 15 18:57:20 2018 +0000 Drop cache values for set_options() params instead of setting cache Partially fixes #25821, which should now fully be implemented --- stem/control.py | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/stem/control.py b/stem/control.py index c67de63c..1bef73b9 100644 --- a/stem/control.py +++ b/stem/control.py @@ -2432,16 +2432,8 @@ class Controller(BaseController): log.debug('%s (runtime: %0.4f)' % (query, time.time() - start_time)) if self.is_caching_enabled(): - to_cache = {} - - for param, value in params: - param = param.lower() - - if stem.util._is_str(value): - value = [value] - - to_cache[param] = value - + # clear cache for params; the CONF_CHANGED event will set cache for changes + to_cache = dict((k.lower(), None) for k, v in params) self._set_cache(to_cache, 'getconf') self._confchanged_cache_invalidation(dict(params)) else:

1 0