November 2015 - tor-commits - lists.torproject.org

[webwml/staging] Donate page: Fix the radio button toggle amount glitch.
by mikeperry＠torproject.org 23 Nov '15

23 Nov '15

commit f59d43d479637a6c722e4b0a276fdde5ee3b946c Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Sun Nov 22 18:33:04 2015 -0800 Donate page: Fix the radio button toggle amount glitch. --- donate/en/donate.wml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/donate/en/donate.wml b/donate/en/donate.wml index 2b8a0b9..18d5fe2 100644 --- a/donate/en/donate.wml +++ b/donate/en/donate.wml @@ -36,7 +36,7 @@ <label class="sr-only" for="exampleInputAmount">1</label> <div class="input-group"> <div class="input-group-addon">$</div> - <input type="text" name="custom_amnt" class="form-control" id="exampleInputAmount" placeholder="1000!?"> + <input type="text" name="custom_amnt" class="form-control" id="exampleInputAmount" placeholder="1000+?"> <div class="input-group-addon">.00</div> </div> </div> @@ -82,7 +82,7 @@ function displayVals() { amount = $( this ).filter("input").val(); if (amount == null) { amount = 100; - } else { + } else if (this.id == "exampleInputAmount") { $( "button" ).removeClass('active'); $( this ).addClass('active'); }

1 0

[translation-tools/master] Added tails-openpgp-applet and tails-openpgp-applet_completed
by colin＠torproject.org 23 Nov '15

23 Nov '15

commit ebb7991aaa725b98d8f696d291b3570064a7cdfc Author: Colin Childs <colin(a)torproject.org> Date: Sun Nov 22 20:26:06 2015 -0600 Added tails-openpgp-applet and tails-openpgp-applet_completed --- config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config b/config index 5548aab..085c082 100644 --- a/config +++ b/config @@ -38,7 +38,7 @@ tor-messenger-imtooltipproperties_completed tor-messenger-ircproperties tor-messenger-ircproperties_completed tor-messenger-otrproperties tor-messenger-otrproperties_completed tor-messenger-loggerproperties tor-messenger-loggerproperties_completed tor-messenger-prefsdtd tor-messenger-privproperties_completed tor-messenger-privdtd tor-messenger-privdtd_completed tor-messenger-prefsdtd -tor-messenger-prefsdtd_completed" +tor-messenger-prefsdtd_completed tails-openpgp-applet tails-openpgp-applet_completed" PIDFILE=/srv/translation.torproject.org/run/update_translations.pid

1 0

[translation/bridgedb] Update translations for bridgedb
by translation＠torproject.org 23 Nov '15

23 Nov '15

commit 39efc048c3e3d17fcaeeab49769184716ef9b06c Author: Translation commit bot <translation(a)torproject.org> Date: Mon Nov 23 01:45:03 2015 +0000 Update translations for bridgedb --- ml/LC_MESSAGES/bridgedb.po | 338 ++++++++++++++++++++++---------------------- 1 file changed, 170 insertions(+), 168 deletions(-) diff --git a/ml/LC_MESSAGES/bridgedb.po b/ml/LC_MESSAGES/bridgedb.po index ec0dafa..467c03f 100644 --- a/ml/LC_MESSAGES/bridgedb.po +++ b/ml/LC_MESSAGES/bridgedb.po @@ -3,17 +3,19 @@ # This file is distributed under the same license as the BridgeDB project. # # Translators: +# Salman Faris <farissalmannbr(a)gmail.com>, 2015 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" -"Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'POT-Creation-Date: 2015-03-19 22:13+0000\n" -"PO-Revision-Date: 2015-04-19 08:23+0000\n" -"Last-Translator: runasand <runa.sandvik(a)gmail.com>\n" -"Language-Team: Malayalam (http://www.transifex.com/projects/p/torproject/language/ml/)\n" +"Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'\n" +"POT-Creation-Date: 2015-07-25 03:40+0000\n" +"PO-Revision-Date: 2015-11-23 01:43+0000\n" +"Last-Translator: Salman Faris <farissalmannbr(a)gmail.com>\n" +"Language-Team: Malayalam (http://www.transifex.com/otf/torproject/language/ml/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 0.9.6\n" +"Generated-By: Babel 1.3\n" "Language: ml\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" @@ -28,57 +30,182 @@ msgstr "" #. "fteproxy" #. "Tor" #. "Tor Browser" -#: lib/bridgedb/HTTPServer.py:107 +#: bridgedb/https/server.py:167 msgid "Sorry! Something went wrong with your request." +msgstr "ക്ഷമിക്കണം! എന്തോ നിങ്ങളുടെ അഭ്യർത്ഥന തെറ്റായി പോയി." + +#: bridgedb/https/templates/base.html:79 +msgid "Report a Bug" +msgstr "ഒരു ബഗ് റിപ്പോർട്ട്" + +#: bridgedb/https/templates/base.html:82 +msgid "Source Code" +msgstr "സോഴ്സ് കോഡ്" + +#: bridgedb/https/templates/base.html:85 +msgid "Changelog" +msgstr "ചേയ്ഞ്ച്ലോഗ്" + +#: bridgedb/https/templates/base.html:88 +msgid "Contact" +msgstr "കോൺടാക്റ്റ്" + +#: bridgedb/https/templates/bridges.html:35 +msgid "Select All" +msgstr "എല്ലാം തിരഞ്ഞെടുക്കുക" + +#: bridgedb/https/templates/bridges.html:40 +msgid "Show QRCode" +msgstr " QRCode കാണിക്കുക" + +#: bridgedb/https/templates/bridges.html:52 +msgid "QRCode for your bridge lines" +msgstr "നിങ്ങളുടെ പാലം ലൈനുകൾ വേണ്ടി QRCode" + +#. TRANSLATORS: Please translate this into some silly way to say +#. "There was a problem!" in your language. For example, +#. for Italian, you might translate this into "Mama mia!", +#. or for French: "Sacrebleu!". :) +#: bridgedb/https/templates/bridges.html:67 +#: bridgedb/https/templates/bridges.html:125 +msgid "Uh oh, spaghettios!" +msgstr "" + +#: bridgedb/https/templates/bridges.html:68 +msgid "It seems there was an error getting your QRCode." +msgstr "" + +#: bridgedb/https/templates/bridges.html:73 +msgid "" +"This QRCode contains your bridge lines. Scan it with a QRCode reader to copy" +" your bridge lines onto mobile and other devices." +msgstr "" + +#: bridgedb/https/templates/bridges.html:131 +msgid "There currently aren't any bridges available..." +msgstr "" + +#: bridgedb/https/templates/bridges.html:132 +#, python-format +msgid "" +" Perhaps you should try %s going back %s and choosing a different bridge " +"type!" +msgstr "" + +#: bridgedb/https/templates/index.html:11 +#, python-format +msgid "Step %s1%s" +msgstr "" + +#: bridgedb/https/templates/index.html:13 +#, python-format +msgid "Download %s Tor Browser %s" +msgstr "" + +#: bridgedb/https/templates/index.html:25 +#, python-format +msgid "Step %s2%s" +msgstr "" + +#: bridgedb/https/templates/index.html:27 +#, python-format +msgid "Get %s bridges %s" +msgstr "" + +#: bridgedb/https/templates/index.html:36 +#, python-format +msgid "Step %s3%s" +msgstr "" + +#: bridgedb/https/templates/index.html:38 +#, python-format +msgid "Now %s add the bridges to Tor Browser %s" +msgstr "" + +#. TRANSLATORS: Please make sure the '%s' surrounding single letters at the +#. beginning of words are present in your final translation. Thanks! +#. (These are used to insert HTML5 underlining tags, to mark accesskeys +#. for disabled users.) +#: bridgedb/https/templates/options.html:38 +#, python-format +msgid "%sJ%sust give me bridges!" +msgstr "" + +#: bridgedb/https/templates/options.html:51 +msgid "Advanced Options" msgstr "" -#: lib/bridgedb/strings.py:18 +#: bridgedb/https/templates/options.html:86 +msgid "No" +msgstr "" + +#: bridgedb/https/templates/options.html:87 +msgid "none" +msgstr "" + +#. TRANSLATORS: Please make sure the '%s' surrounding single letters at the +#. beginning of words are present in your final translation. Thanks! +#. TRANSLATORS: Translate "Yes!" as in "Yes! I do need IPv6 addresses." +#: bridgedb/https/templates/options.html:124 +#, python-format +msgid "%sY%ses!" +msgstr "" + +#. TRANSLATORS: Please make sure the '%s' surrounding single letters at the +#. beginning of words are present in your final translation. Thanks! +#. TRANSLATORS: Please do NOT translate the word "bridge"! +#: bridgedb/https/templates/options.html:147 +#, python-format +msgid "%sG%set Bridges" +msgstr "" + +#: bridgedb/strings.py:43 msgid "[This is an automated message; please do not reply.]" msgstr "" -#: lib/bridgedb/strings.py:20 +#: bridgedb/strings.py:45 msgid "Here are your bridges:" msgstr "" -#: lib/bridgedb/strings.py:22 +#: bridgedb/strings.py:47 #, python-format msgid "" "You have exceeded the rate limit. Please slow down! The minimum time between\n" "emails is %s hours. All further emails during this time period will be ignored." msgstr "" -#: lib/bridgedb/strings.py:25 +#: bridgedb/strings.py:50 msgid "" "COMMANDs: (combine COMMANDs to specify multiple options simultaneously)" msgstr "" #. TRANSLATORS: Please DO NOT translate the word "BridgeDB". -#: lib/bridgedb/strings.py:28 +#: bridgedb/strings.py:53 msgid "Welcome to BridgeDB!" msgstr "" #. TRANSLATORS: Please DO NOT translate the words "transport" or "TYPE". -#: lib/bridgedb/strings.py:30 +#: bridgedb/strings.py:55 msgid "Currently supported transport TYPEs:" msgstr "" -#: lib/bridgedb/strings.py:31 +#: bridgedb/strings.py:56 #, python-format msgid "Hey, %s!" msgstr "" -#: lib/bridgedb/strings.py:32 +#: bridgedb/strings.py:57 msgid "Hello, friend!" msgstr "" -#: lib/bridgedb/strings.py:33 lib/bridgedb/templates/base.html:100 +#: bridgedb/strings.py:58 bridgedb/https/templates/base.html:90 msgid "Public Keys" msgstr "" #. TRANSLATORS: This string will end up saying something like: #. "This email was generated with rainbows, unicorns, and sparkles #. for alice(a)example.com on Friday, 09 May, 2014 at 18:59:39." -#: lib/bridgedb/strings.py:37 +#: bridgedb/strings.py:62 #, python-format msgid "" "This email was generated with rainbows, unicorns, and sparkles\n" @@ -89,7 +216,7 @@ msgstr "" #. TRANSLATORS: Please DO NOT translate "Pluggable Transports". #. TRANSLATORS: Please DO NOT translate "Tor". #. TRANSLATORS: Please DO NOT translate "Tor Network". -#: lib/bridgedb/strings.py:47 +#: bridgedb/strings.py:72 #, python-format msgid "" "BridgeDB can provide bridges with several %stypes of Pluggable Transports%s,\n" @@ -100,7 +227,7 @@ msgid "" msgstr "" #. TRANSLATORS: Please DO NOT translate "Pluggable Transports". -#: lib/bridgedb/strings.py:54 +#: bridgedb/strings.py:79 msgid "" "Some bridges with IPv6 addresses are also available, though some Pluggable\n" "Transports aren't IPv6 compatible.\n" @@ -112,7 +239,7 @@ msgstr "" #. regular, or unexciting". Like vanilla ice cream. It refers to bridges #. which do not have Pluggable Transports, and only speak the regular, #. boring Tor protocol. Translate it as you see fit. Have fun with it. -#: lib/bridgedb/strings.py:63 +#: bridgedb/strings.py:88 #, python-format msgid "" "Additionally, BridgeDB has plenty of plain-ol'-vanilla bridges %s without any\n" @@ -121,20 +248,20 @@ msgid "" "\n" msgstr "" -#: lib/bridgedb/strings.py:76 +#: bridgedb/strings.py:101 msgid "What are bridges?" msgstr "" -#: lib/bridgedb/strings.py:77 +#: bridgedb/strings.py:102 #, python-format msgid "%s Bridges %s are Tor relays that help you circumvent censorship." msgstr "" -#: lib/bridgedb/strings.py:82 +#: bridgedb/strings.py:107 msgid "I need an alternative way of getting bridges!" msgstr "" -#: lib/bridgedb/strings.py:83 +#: bridgedb/strings.py:108 #, python-format msgid "" "Another way to get bridges is to send an email to %s. Please note that you must\n" @@ -142,12 +269,12 @@ msgid "" "%s, %s or %s." msgstr "" -#: lib/bridgedb/strings.py:90 +#: bridgedb/strings.py:115 msgid "My bridges don't work! I need help!" msgstr "" #. TRANSLATORS: Please DO NOT translate "Tor". -#: lib/bridgedb/strings.py:92 +#: bridgedb/strings.py:117 #, python-format msgid "If your Tor doesn't work, you should email %s." msgstr "" @@ -155,48 +282,48 @@ msgstr "" #. TRANSLATORS: Please DO NOT translate "Pluggable Transports". #. TRANSLATORS: Please DO NOT translate "Tor Browser". #. TRANSLATORS: Please DO NOT translate "Tor". -#: lib/bridgedb/strings.py:96 +#: bridgedb/strings.py:121 msgid "" "Try including as much info about your case as you can, including the list of\n" "bridges and Pluggable Transports you tried to use, your Tor Browser version,\n" "and any messages which Tor gave out, etc." msgstr "" -#: lib/bridgedb/strings.py:103 +#: bridgedb/strings.py:128 msgid "Here are your bridge lines:" msgstr "" -#: lib/bridgedb/strings.py:104 +#: bridgedb/strings.py:129 msgid "Get Bridges!" msgstr "" -#: lib/bridgedb/strings.py:108 +#: bridgedb/strings.py:133 msgid "Please select options for bridge type:" msgstr "" -#: lib/bridgedb/strings.py:109 +#: bridgedb/strings.py:134 msgid "Do you need IPv6 addresses?" msgstr "" -#: lib/bridgedb/strings.py:110 +#: bridgedb/strings.py:135 #, python-format msgid "Do you need a %s?" msgstr "" -#: lib/bridgedb/strings.py:114 +#: bridgedb/strings.py:139 msgid "Your browser is not displaying images properly." msgstr "" -#: lib/bridgedb/strings.py:115 +#: bridgedb/strings.py:140 msgid "Enter the characters from the image above..." msgstr "" -#: lib/bridgedb/strings.py:119 +#: bridgedb/strings.py:144 msgid "How to start using your bridges" msgstr "" #. TRANSLATORS: Please DO NOT translate "Tor Browser". -#: lib/bridgedb/strings.py:121 +#: bridgedb/strings.py:146 #, python-format msgid "" "To enter bridges into Tor Browser, first go to the %s Tor Browser download\n" @@ -205,21 +332,21 @@ msgid "" msgstr "" #. TRANSLATORS: Please DO NOT translate "Tor". -#: lib/bridgedb/strings.py:126 +#: bridgedb/strings.py:151 msgid "" "When the 'Tor Network Settings' dialogue pops up, click 'Configure' and follow\n" "the wizard until it asks:" msgstr "" #. TRANSLATORS: Please DO NOT translate "Tor". -#: lib/bridgedb/strings.py:130 +#: bridgedb/strings.py:155 msgid "" "Does your Internet Service Provider (ISP) block or otherwise censor connections\n" "to the Tor network?" msgstr "" #. TRANSLATORS: Please DO NOT translate "Tor". -#: lib/bridgedb/strings.py:134 +#: bridgedb/strings.py:159 msgid "" "Select 'Yes' and then click 'Next'. To configure your new bridges, copy and\n" "paste the bridge lines into the text input box. Finally, click 'Connect', and\n" @@ -227,153 +354,28 @@ msgid "" "button in the 'Tor Network Settings' wizard for further assistance." msgstr "" -#: lib/bridgedb/strings.py:142 +#: bridgedb/strings.py:167 msgid "Displays this message." msgstr "" #. TRANSLATORS: Please try to make it clear that "vanilla" here refers to the #. same non-Pluggable Transport bridges described above as being #. "plain-ol'-vanilla" bridges. -#: lib/bridgedb/strings.py:146 +#: bridgedb/strings.py:171 msgid "Request vanilla bridges." msgstr "" -#: lib/bridgedb/strings.py:147 +#: bridgedb/strings.py:172 msgid "Request IPv6 bridges." msgstr "" #. TRANSLATORS: Please DO NOT translate the word the word "TYPE". -#: lib/bridgedb/strings.py:149 +#: bridgedb/strings.py:174 msgid "Request a Pluggable Transport by TYPE." msgstr "" #. TRANSLATORS: Please DO NOT translate "BridgeDB". #. TRANSLATORS: Please DO NOT translate "GnuPG". -#: lib/bridgedb/strings.py:152 +#: bridgedb/strings.py:177 msgid "Get a copy of BridgeDB's public GnuPG key." msgstr "" - -#: lib/bridgedb/templates/base.html:89 -msgid "Report a Bug" -msgstr "" - -#: lib/bridgedb/templates/base.html:92 -msgid "Source Code" -msgstr "" - -#: lib/bridgedb/templates/base.html:95 -msgid "Changelog" -msgstr "" - -#: lib/bridgedb/templates/base.html:98 -msgid "Contact" -msgstr "" - -#: lib/bridgedb/templates/bridges.html:81 -msgid "Select All" -msgstr "" - -#: lib/bridgedb/templates/bridges.html:87 -msgid "Show QRCode" -msgstr "" - -#: lib/bridgedb/templates/bridges.html:100 -msgid "QRCode for your bridge lines" -msgstr "" - -#. TRANSLATORS: Please translate this into some silly way to say -#. "There was a problem!" in your language. For example, -#. for Italian, you might translate this into "Mama mia!", -#. or for French: "Sacrebleu!". :) -#: lib/bridgedb/templates/bridges.html:115 -#: lib/bridgedb/templates/bridges.html:175 -msgid "Uh oh, spaghettios!" -msgstr "" - -#: lib/bridgedb/templates/bridges.html:116 -msgid "It seems there was an error getting your QRCode." -msgstr "" - -#: lib/bridgedb/templates/bridges.html:121 -msgid "" -"This QRCode contains your bridge lines. Scan it with a QRCode reader to copy" -" your bridge lines onto mobile and other devices." -msgstr "" - -#: lib/bridgedb/templates/bridges.html:181 -msgid "There currently aren't any bridges available..." -msgstr "" - -#: lib/bridgedb/templates/bridges.html:182 -#, python-format -msgid "" -" Perhaps you should try %s going back %s and choosing a different bridge " -"type!" -msgstr "" - -#: lib/bridgedb/templates/index.html:11 -#, python-format -msgid "Step %s1%s" -msgstr "" - -#: lib/bridgedb/templates/index.html:13 -#, python-format -msgid "Download %s Tor Browser %s" -msgstr "" - -#: lib/bridgedb/templates/index.html:25 -#, python-format -msgid "Step %s2%s" -msgstr "" - -#: lib/bridgedb/templates/index.html:27 -#, python-format -msgid "Get %s bridges %s" -msgstr "" - -#: lib/bridgedb/templates/index.html:36 -#, python-format -msgid "Step %s3%s" -msgstr "" - -#: lib/bridgedb/templates/index.html:38 -#, python-format -msgid "Now %s add the bridges to Tor Browser %s" -msgstr "" - -#. TRANSLATORS: Please make sure the '%s' surrounding single letters at the -#. beginning of words are present in your final translation. Thanks! -#. (These are used to insert HTML5 underlining tags, to mark accesskeys -#. for disabled users.) -#: lib/bridgedb/templates/options.html:38 -#, python-format -msgid "%sJ%sust give me bridges!" -msgstr "" - -#: lib/bridgedb/templates/options.html:52 -msgid "Advanced Options" -msgstr "" - -#: lib/bridgedb/templates/options.html:88 -msgid "No" -msgstr "" - -#: lib/bridgedb/templates/options.html:89 -msgid "none" -msgstr "" - -#. TRANSLATORS: Please make sure the '%s' surrounding single letters at the -#. beginning of words are present in your final translation. Thanks! -#. TRANSLATORS: Translate "Yes!" as in "Yes! I do need IPv6 addresses." -#: lib/bridgedb/templates/options.html:127 -#, python-format -msgid "%sY%ses!" -msgstr "" - -#. TRANSLATORS: Please make sure the '%s' surrounding single letters at the -#. beginning of words are present in your final translation. Thanks! -#. TRANSLATORS: Please do NOT translate the word "bridge"! -#: lib/bridgedb/templates/options.html:151 -#, python-format -msgid "%sG%set Bridges" -msgstr ""

1 0

[webwml/master] Have the website admit that 0.2.7.5 is stable
by nickm＠torproject.org 23 Nov '15

23 Nov '15

commit 9944a0e37db47dcf39d752beacb3c0820095c17d Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Nov 22 20:39:21 2015 -0500 Have the website admit that 0.2.7.5 is stable --- Makefile | 2 +- include/versions.wmi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 16a3328..7897228 100644 --- a/Makefile +++ b/Makefile @@ -15,7 +15,7 @@ # website component, and set it to needs_review. export STABLETAG=tor-0.2.6.10 -export DEVTAG=tor-0.2.7.4-rc +export DEVTAG=tor-0.2.7.5 WMLBASE=. diff --git a/include/versions.wmi b/include/versions.wmi index 7a22419..e05d00c 100644 --- a/include/versions.wmi +++ b/include/versions.wmi @@ -1,5 +1,5 @@ <define-tag version-stable whitespace=delete>0.2.6.10</define-tag> -<define-tag version-alpha whitespace=delete>0.2.7.4-rc</define-tag> +<define-tag version-alpha whitespace=delete>0.2.7.5</define-tag> <define-tag version-win32-stable whitespace=delete>0.2.6.10</define-tag>

1 0

[webwml/staging] remove the ccc donations option
by arma＠torproject.org 22 Nov '15

22 Nov '15

commit c8dba8e94ed43e657235c42fc7c72efcaa7cc097 Author: Roger Dingledine <arma(a)torproject.org> Date: Sun Nov 22 17:56:51 2015 -0500 remove the ccc donations option since we don't have visibility into what they get or how it gets spent, and julius and andreas both suggest removing it. --- donate/en/donate-options.wml | 28 ---------------------------- 1 file changed, 28 deletions(-) diff --git a/donate/en/donate-options.wml b/donate/en/donate-options.wml index 3aeed1a..ba41c37 100644 --- a/donate/en/donate-options.wml +++ b/donate/en/donate-options.wml @@ -156,34 +156,6 @@ href="https://www.dwolla.com/hub/thetorproject">Continue to Dwolla 7 Temple Street, Suite A<br> Cambridge, MA 02139-2403 USA</p>  - - <h3 style="margin-top:20px;">Donate via European Bank Transfer</h3> - <p><em>For European bank transfers, we have an arrangement with - <a href="http://www.ccc.de/">CCC in Germany</a> to provide - tax-deductible donations for Europeans:</em></p> - <p>Wau Holland Stiftung<br> - Commerzbank Kassel<br> - BLZ: 52040021<br> - Konto: 2772812-02<br> - IBAN: DE03 5204 0021 0277 2812 02<br> - BIC: COBADEFF520 *or* COBADEFFXXX</p> - <ul> - <li>Residents from any of the 31 <a - href="http://en.wikipedia.org/wiki/Single_Euro_Payments_Area">SEPA</a> - member states can wire up to 50.000 Euro at the cost of - a domestic transaction (i.e., usually free if submitted - electronically).</li> - <li>European citizens can make a charitable contribution that - is tax-deductible to a certain degree (Germany: max 20% of total income). - </li> - <li>Corporate entities can deduct donations up to 4/1000 of - their combined turnovers, wages and salaries. WHS issues - a donation receipt upon request (if provided with address - information).</li> - </ul> - </div> - </div> -  </div> <div id = "sidecol">

1 0

[tor-messenger-build/master] Update ChangeLog for b4 release
by sukhbir＠torproject.org 22 Nov '15

22 Nov '15

commit b6751ae99e2f22f47c1e0cf573f5c63373dad032 Author: Sukhbir Singh <sukhbir(a)torproject.org> Date: Sun Nov 22 17:24:22 2015 -0500 Update ChangeLog for b4 release --- ChangeLog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 058bde8..7cc9673 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,4 @@ -Tor Messenger 0.1.0b4 -- +Tor Messenger 0.1.0b4 -- November 22 2015 * All Platforms * Bug 17492: Include default bridges configuration * Use tor and the pluggable transports from tor-browser 5.0.4

1 0

[translation/liveusb-creator_completed] Update translations for liveusb-creator_completed
by translation＠torproject.org 22 Nov '15

22 Nov '15

commit 088fdda73948a60a25b1d2b932ba796096983b68 Author: Translation commit bot <translation(a)torproject.org> Date: Sun Nov 22 02:15:27 2015 +0000 Update translations for liveusb-creator_completed --- en_GB/en_GB.po | 140 ++++++++++++++++++++++++++++++-------------------------- 1 file changed, 75 insertions(+), 65 deletions(-) diff --git a/en_GB/en_GB.po b/en_GB/en_GB.po index ea56dc8..8563f99 100644 --- a/en_GB/en_GB.po +++ b/en_GB/en_GB.po @@ -3,7 +3,7 @@ # This file is distributed under the same license as the PACKAGE package. # # Translators: -# Andi Chandler <andi(a)gowling.com>, 2014 +# Andi Chandler <andi(a)gowling.com>, 2014-2015 # Bruce Cowan <bcowan(a)fastmail.co.uk>, 2010 # Foorack <maxfaxalv(a)gmail.com>, 2015 # Isabell Long <isabell(a)issyl0.co.uk>, 2015 @@ -14,9 +14,9 @@ msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2015-08-04 10:45+0200\n" -"PO-Revision-Date: 2015-08-10 21:37+0000\n" -"Last-Translator: Isabell Long <isabell(a)issyl0.co.uk>\n" +"POT-Creation-Date: 2015-11-02 21:23+0100\n" +"PO-Revision-Date: 2015-11-22 02:09+0000\n" +"Last-Translator: Andi Chandler <andi(a)gowling.com>\n" "Language-Team: English (United Kingdom) (http://www.transifex.com/otf/torproject/language/en_GB/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -32,7 +32,7 @@ msgstr "\"Clone & Install\"" msgid "\"Install from ISO\"" msgstr "\"Install from ISO\"" -#: ../liveusb/dialog.py:150 ../liveusb/launcher_ui.py:149 +#: ../liveusb/dialog.py:157 ../liveusb/launcher_ui.py:153 #, python-format msgid "%(distribution)s Installer" msgstr "%(distribution)s Installer" @@ -57,51 +57,61 @@ msgstr "%(vendor)s %(model)s (%(details)s) - %(device)s" msgid "%s already bootable" msgstr "%s already bootable" -#: ../liveusb/launcher_ui.py:156 -msgid "" -"<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n" -"<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\n" -"p, li { white-space: pre-wrap; }\n" -"</style></head><body style=\" font-family:'Sans Serif'; font-size:11pt; font-weight:400; font-style:normal;\">\n" -"<p align=\"center\" style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\"><span style=\" font-size:11pt;\">Need help? Read the </span><a href=\"file:///usr/share/doc/tails/website/doc/first_steps/installation.en.html\"><span style=\" text-decoration: underline; color:#0000ff;\">documentation</span></a><span style=\" font-size:11pt;\">.</span></p></body></html>" -msgstr "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\np, li { white-space: pre-wrap; }\n</style></head><body style=\" font-family:'Sans Serif'; font-size:11pt; font-weight:400; font-style:normal;\">\n<p align=\"center\" style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\"><span style=\" font-size:11pt;\">Need help? Read the </span><a href=\"file:///usr/share/doc/tails/website/doc/first_steps/installation.en.html\"><span style=\" text-decoration: underline; color:#0000ff;\">documentation</span></a><span style=\" font-size:11pt;\">.</span></p></body></html>" - -#: ../liveusb/launcher_ui.py:151 -msgid "" -"<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n" -"<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\n" -"p, li { white-space: pre-wrap; }\n" -"</style></head><body style=\" font-family:'Sans Serif'; font-size:11pt; font-weight:400; font-style:normal;\">\n" -"<p style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\"><span style=\" font-size:11pt;\">Copy the running Tails onto a USB stick or SD card. All data on the target drive will be lost.</span></p></body></html>" -msgstr "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\np, li { white-space: pre-wrap; }\n</style></head><body style=\" font-family:'Sans Serif'; font-size:11pt; font-weight:400; font-style:normal;\">\n<p style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\"><span style=\" font-size:11pt;\">Copy the running Tails onto a USB stick or SD card. All data on the target drive will be lost.</span></p></body></html>" - -#: ../liveusb/launcher_ui.py:153 +#: ../liveusb/launcher_ui.py:160 msgid "" "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n" "<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\n" "p, li { white-space: pre-wrap; }\n" -"</style></head><body style=\" font-family:'Sans Serif'; font-size:11pt; font-weight:400; font-style:normal;\">\n" -"<p style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\"><span style=\" font-size:11pt;\">Copy the running Tails onto an already installed Tails device. Other partitions found on the stick are preserved.</span></p></body></html>" -msgstr "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\np, li { white-space: pre-wrap; }\n</style></head><body style=\" font-family:'Sans Serif'; font-size:11pt; font-weight:400; font-style:normal;\">\n<p style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\"><span style=\" font-size:11pt;\">Copy the running Tails onto an already installed Tails device. Other partitions found on the stick are preserved.</span></p></body></html>" +"</style></head><body style=\" font-family:'Cantarell'; font-size:11pt; font-weight:400; font-style:normal;\">\n" +"<p align=\"center\" style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\">Need help? Read the <a href=\"file:///usr/share/doc/tails/website/doc/first_steps/installation.en.html\"><span style=\" text-decoration: underline; color:#0000ff;\">documentation</span></a>.</p></body></html>" +msgstr "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\np, li { white-space: pre-wrap; }\n</style></head><body style=\" font-family:'Cantarell'; font-size:11pt; font-weight:400; font-style:normal;\">\n<p align=\"center\" style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\">Need help? Read the <a href=\"file:///usr/share/doc/tails/website/doc/first_steps/installation.en.html\"><span style=\" text-decoration: underline; color:#0000ff;\">documentation</span></a>.</p></body></html>" #: ../liveusb/launcher_ui.py:155 msgid "" -"<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n" -"<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\n" -"p, li { white-space: pre-wrap; }\n" -"</style></head><body style=\" font-family:'Sans Serif'; font-size:11pt; font-weight:400; font-style:normal;\">\n" -"<p style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\"><span style=\" font-size:11pt;\">Upgrade an already installed Tails device from a new ISO image.</span></p></body></html>" -msgstr "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\np, li { white-space: pre-wrap; }\n</style></head><body style=\" font-family:'Sans Serif'; font-size:11pt; font-weight:400; font-style:normal;\">\n<p style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\"><span style=\" font-size:11pt;\">Upgrade an already installed Tails device from a new ISO image.</span></p></body></html>" +"<ul>\n" +"<li>Install Tails on another USB stick by copying the Tails system that you are currently using..</li>\n" +"\n" +"<li>The USB stick that you install on is formatted and all data is lost.</li>\n" +"\n" +"<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n" +"\n" +"</ul>" +msgstr "<ul>\n<li>Install Tails on another USB stick by copying the Tails system that you are currently using..</li>\n\n<li>The USB stick that you install on is formatted and all data is lost.</li>\n\n<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n\n</ul>" + +#: ../liveusb/launcher_ui.py:157 +msgid "" +"<ul>\n" +"<li>Upgrade another Tails USB stick to the same version of Tails that you are currently using.</li>\n" +"\n" +"<li>The encrypted persistent storage of the Tails USB stick that you upgrade is preserved.</li>\n" +"\n" +"<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n" +"\n" +"\n" +"</ul>" +msgstr "<ul>\n<li>Upgrade another Tails USB stick to the same version of Tails that you are currently using.</li>\n\n<li>The encrypted persistent storage of the Tails USB stick that you upgrade is preserved.</li>\n\n<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n\n\n</ul>" + +#: ../liveusb/launcher_ui.py:159 +msgid "" +"<ul>\n" +"<li>Upgrade another Tails USB stick to the version of an ISO image.</li>\n" +"\n" +"<li>The encrypted persistent storage of the Tails USB stick that you upgrade is preserved.</li>\n" +"\n" +"<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n" +"\n" +"</ul>" +msgstr "<ul>\n<li>Upgrade another Tails USB stick to the version of an ISO image.</li>\n\n<li>The encrypted persistent storage of the Tails USB stick that you upgrade is preserved.</li>\n\n<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n\n</ul>" -#: ../liveusb/dialog.py:154 +#: ../liveusb/dialog.py:161 msgid "Alt+B" msgstr "Alt+B" -#: ../liveusb/dialog.py:153 +#: ../liveusb/dialog.py:160 msgid "Browse" msgstr "Browse" -#: ../liveusb/dialog.py:160 +#: ../liveusb/dialog.py:167 msgid "" "By allocating extra space on your USB stick for a persistent overlay, you " "will be able to store data and make permanent modifications to your live " @@ -123,20 +133,6 @@ msgstr "Cannot find" msgid "Cannot find device %s" msgstr "Cannot find device %s" -#: ../liveusb/launcher_ui.py:150 -msgid "" -"Clone\n" -"&&\n" -"Install" -msgstr "Clone\n&&\nInstall" - -#: ../liveusb/launcher_ui.py:152 -msgid "" -"Clone\n" -"&&\n" -"Upgrade" -msgstr "Clone\n&&\nUpgrade" - #: ../liveusb/creator.py:417 #, python-format msgid "Creating %sMB persistent overlay" @@ -147,7 +143,7 @@ msgid "" "Device is not yet mounted, so we cannot determine the amount of free space." msgstr "Device is not yet mounted, so we cannot determine the amount of free space." -#: ../liveusb/dialog.py:157 +#: ../liveusb/dialog.py:164 #, python-format msgid "Download %(distribution)s" msgstr "Download %(distribution)s" @@ -207,13 +203,19 @@ msgstr "ISO MD5 checksum passed" msgid "ISO MD5 checksum verification failed" msgstr "ISO MD5 checksum verification failed" -#: ../liveusb/dialog.py:156 +#: ../liveusb/dialog.py:163 msgid "" "If you do not select an existing Live ISO, the selected release will be " "downloaded for you." msgstr "If you do not select an existing Live ISO, the selected release will be downloaded for you." -#: ../liveusb/dialog.py:165 +#: ../liveusb/launcher_ui.py:154 +msgid "" +"Install\n" +"by cloning" +msgstr "Install\nby cloning" + +#: ../liveusb/dialog.py:172 msgid "Install Tails" msgstr "Install Tails" @@ -295,7 +297,7 @@ msgstr "Partitioning device %(device)s" msgid "Persistent Storage" msgstr "Persistent Storage" -#: ../liveusb/dialog.py:161 +#: ../liveusb/dialog.py:168 msgid "Persistent Storage (0 MB)" msgstr "Persistent Storage (0 MB)" @@ -349,7 +351,7 @@ msgstr "Source type does not support verification of ISO MD5 checksum, skipping" msgid "Synchronizing data on disk..." msgstr "Synchronizing data on disk..." -#: ../liveusb/dialog.py:159 +#: ../liveusb/dialog.py:166 msgid "Target Device" msgstr "Target Device" @@ -373,14 +375,14 @@ msgid "" "A more detailed error log has been written to '%(filename)s'." msgstr "There was a problem executing the following command: `%(command)s`.\nA more detailed error log has been written to '%(filename)s'." -#: ../liveusb/dialog.py:151 +#: ../liveusb/dialog.py:158 msgid "" "This button allows you to browse for an existing Live system ISO that you " "have previously downloaded. If you do not select one, a release will be " "downloaded for you automatically." msgstr "This button allows you to browse for an existing Live system ISO that you have previously downloaded. If you do not select one, a release will be downloaded for you automatically." -#: ../liveusb/dialog.py:164 +#: ../liveusb/dialog.py:171 msgid "" "This button will begin the LiveUSB creation process. This entails " "optionally downloading a release (if an existing one wasn't selected), " @@ -388,19 +390,19 @@ msgid "" "installing the bootloader." msgstr "This button will begin the LiveUSB creation process. This entails optionally downloading a release (if an existing one wasn't selected), extracting the ISO to the USB device, creating the persistent overlay, and installing the bootloader." -#: ../liveusb/dialog.py:158 +#: ../liveusb/dialog.py:165 msgid "" "This is the USB stick that you want to install your Live system on. This " "device must be formatted with the FAT filesystem." msgstr "This is the USB stick that you want to install your Live system on. This device must be formatted with the FAT filesystem." -#: ../liveusb/dialog.py:163 +#: ../liveusb/dialog.py:170 msgid "" "This is the progress bar that will indicate how far along in the LiveUSB " "creation process you are" msgstr "This is the progress bar that will indicate how far along in the LiveUSB creation process you are" -#: ../liveusb/dialog.py:162 +#: ../liveusb/dialog.py:169 msgid "This is the status console, where all messages get written to." msgstr "This is the status console, where all messages get written to." @@ -529,11 +531,19 @@ msgstr "Unsupported filesystem: %s\nPlease backup and format your USB key with t msgid "Updating properties of system partition %(system_partition)s" msgstr "Updating properties of system partition %(system_partition)s" -#: ../liveusb/launcher_ui.py:154 -msgid "Upgrade from ISO" -msgstr "Upgrade from ISO" +#: ../liveusb/launcher_ui.py:156 +msgid "" +"Upgrade\n" +"by cloning" +msgstr "Upgrade\nby cloning" + +#: ../liveusb/launcher_ui.py:158 +msgid "" +"Upgrade\n" +"from ISO" +msgstr "Upgrade\nfrom ISO" -#: ../liveusb/dialog.py:152 +#: ../liveusb/dialog.py:159 msgid "Use existing Live system ISO" msgstr "Use existing Live system ISO" @@ -599,6 +609,6 @@ msgstr "You can try again to resume your download" msgid "You must run this application as root" msgstr "You must run this application as root" -#: ../liveusb/dialog.py:155 +#: ../liveusb/dialog.py:162 msgid "or" msgstr "or"

1 0

[translation/liveusb-creator] Update translations for liveusb-creator
by translation＠torproject.org 22 Nov '15

22 Nov '15

commit de49b06ee64f9de7af4074560f7d6a4591836389 Author: Translation commit bot <translation(a)torproject.org> Date: Sun Nov 22 02:15:19 2015 +0000 Update translations for liveusb-creator --- en_GB/en_GB.po | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/en_GB/en_GB.po b/en_GB/en_GB.po index b4d6fbd..8563f99 100644 --- a/en_GB/en_GB.po +++ b/en_GB/en_GB.po @@ -3,7 +3,7 @@ # This file is distributed under the same license as the PACKAGE package. # # Translators: -# Andi Chandler <andi(a)gowling.com>, 2014 +# Andi Chandler <andi(a)gowling.com>, 2014-2015 # Bruce Cowan <bcowan(a)fastmail.co.uk>, 2010 # Foorack <maxfaxalv(a)gmail.com>, 2015 # Isabell Long <isabell(a)issyl0.co.uk>, 2015 @@ -15,8 +15,8 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2015-11-02 21:23+0100\n" -"PO-Revision-Date: 2015-11-03 09:24+0000\n" -"Last-Translator: carolyn <carolyn(a)anhalt.org>\n" +"PO-Revision-Date: 2015-11-22 02:09+0000\n" +"Last-Translator: Andi Chandler <andi(a)gowling.com>\n" "Language-Team: English (United Kingdom) (http://www.transifex.com/otf/torproject/language/en_GB/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -64,7 +64,7 @@ msgid "" "p, li { white-space: pre-wrap; }\n" "</style></head><body style=\" font-family:'Cantarell'; font-size:11pt; font-weight:400; font-style:normal;\">\n" "<p align=\"center\" style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\">Need help? Read the <a href=\"file:///usr/share/doc/tails/website/doc/first_steps/installation.en.html\"><span style=\" text-decoration: underline; color:#0000ff;\">documentation</span></a>.</p></body></html>" -msgstr "" +msgstr "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">\n<html><head><meta name=\"qrichtext\" content=\"1\" /><style type=\"text/css\">\np, li { white-space: pre-wrap; }\n</style></head><body style=\" font-family:'Cantarell'; font-size:11pt; font-weight:400; font-style:normal;\">\n<p align=\"center\" style=\" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;\">Need help? Read the <a href=\"file:///usr/share/doc/tails/website/doc/first_steps/installation.en.html\"><span style=\" text-decoration: underline; color:#0000ff;\">documentation</span></a>.</p></body></html>" #: ../liveusb/launcher_ui.py:155 msgid "" @@ -76,7 +76,7 @@ msgid "" "<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n" "\n" "</ul>" -msgstr "" +msgstr "<ul>\n<li>Install Tails on another USB stick by copying the Tails system that you are currently using..</li>\n\n<li>The USB stick that you install on is formatted and all data is lost.</li>\n\n<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n\n</ul>" #: ../liveusb/launcher_ui.py:157 msgid "" @@ -89,7 +89,7 @@ msgid "" "\n" "\n" "</ul>" -msgstr "" +msgstr "<ul>\n<li>Upgrade another Tails USB stick to the same version of Tails that you are currently using.</li>\n\n<li>The encrypted persistent storage of the Tails USB stick that you upgrade is preserved.</li>\n\n<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n\n\n</ul>" #: ../liveusb/launcher_ui.py:159 msgid "" @@ -101,7 +101,7 @@ msgid "" "<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n" "\n" "</ul>" -msgstr "" +msgstr "<ul>\n<li>Upgrade another Tails USB stick to the version of an ISO image.</li>\n\n<li>The encrypted persistent storage of the Tails USB stick that you upgrade is preserved.</li>\n\n<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n\n</ul>" #: ../liveusb/dialog.py:161 msgid "Alt+B" @@ -213,7 +213,7 @@ msgstr "If you do not select an existing Live ISO, the selected release will be msgid "" "Install\n" "by cloning" -msgstr "" +msgstr "Install\nby cloning" #: ../liveusb/dialog.py:172 msgid "Install Tails" @@ -535,13 +535,13 @@ msgstr "Updating properties of system partition %(system_partition)s" msgid "" "Upgrade\n" "by cloning" -msgstr "" +msgstr "Upgrade\nby cloning" #: ../liveusb/launcher_ui.py:158 msgid "" "Upgrade\n" "from ISO" -msgstr "" +msgstr "Upgrade\nfrom ISO" #: ../liveusb/dialog.py:159 msgid "Use existing Live system ISO"

1 0

[translation/mat-gui] Update translations for mat-gui
by translation＠torproject.org 21 Nov '15

21 Nov '15

commit 08f6ea4d5eae3aefde991163f69fe297e3494275 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Nov 21 19:15:30 2015 +0000 Update translations for mat-gui --- ka.po | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ka.po b/ka.po index 9d5a1bf..05801ee 100644 --- a/ka.po +++ b/ka.po @@ -9,9 +9,9 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2014-12-31 04:53+0100\n" -"PO-Revision-Date: 2015-06-25 16:43+0000\n" +"PO-Revision-Date: 2015-11-21 18:52+0000\n" "Last-Translator: George Salukvadze <giosal90(a)gmail.com>\n" -"Language-Team: Georgian (http://www.transifex.com/projects/p/torproject/language/ka/)\n" +"Language-Team: Georgian (http://www.transifex.com/otf/torproject/language/ka/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" @@ -78,7 +78,7 @@ msgstr "არა მხარდაჭერილი ფაილების #: mat-gui:232 msgid "Add non-supported (and so non-anonymised) file to output archive" -msgstr "" +msgstr "გამომავალ არქივში არა-მხარდაჭერილი (და ასე-არა-ანონიმიზირებული) ფაილის დამატება" #: mat-gui:271 msgid "Unknown" @@ -90,7 +90,7 @@ msgstr "არა მხარდაჭერილი" #: mat-gui:328 msgid "Harmless fileformat" -msgstr "" +msgstr "არამავნე ფაილის ფორმატი" #: mat-gui:330 msgid "Fileformat not supported" @@ -110,7 +110,7 @@ msgstr "მიზეზი" #: mat-gui:352 msgid "Non-supported files in archive" -msgstr "" +msgstr "არა-მხარდაჭერილი ფაილები არქივში" #: mat-gui:366 msgid "Include"

1 0

[torspec/master] Give rend-single-onion a number (260)
by nickm＠torproject.org 21 Nov '15

21 Nov '15

commit 7ba7b2ca764422232e534d84ec7c87373e0769af Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Nov 20 22:34:34 2015 -0500 Give rend-single-onion a number (260) --- proposals/000-index.txt | 2 + proposals/260-rend-single-onion.txt | 460 +++++++++++++++++++++++++++++ proposals/ideas/xxx-rend-single-onion.txt | 460 ----------------------------- 3 files changed, 462 insertions(+), 460 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 871dfcb..8dcbe26 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -180,6 +180,7 @@ Proposals by number: 257 Refactoring authorities and taking parts offline [DRAFT] 258 Denial-of-service resistance for directory authorities [OPEN] 259 New Guard Selection Behaviour [DRAFT] +260 Rendezvous Single Onion Services [DRAFT] Proposals by status: @@ -205,6 +206,7 @@ Proposals by status: 255 Controller features to allow for load-balancing hidden services 257 Refactoring authorities and taking parts offline 259 New Guard Selection Behaviour + 260 Rendezvous Single Onion Services NEEDS-REVISION: 190 Bridge Client Authorization Based on a Shared Secret OPEN: diff --git a/proposals/260-rend-single-onion.txt b/proposals/260-rend-single-onion.txt new file mode 100644 index 0000000..fc01551 --- /dev/null +++ b/proposals/260-rend-single-onion.txt @@ -0,0 +1,460 @@ +Filename: 260-rend-single-onion.txt +Title: Rendezvous Single Onion Services +Author: Tim Wilson-Brown, John Brooks, Aaron Johnson, Rob Jansen, George Kadianakis, Paul Syverson, Roger Dingledine +Created: 2015-10-17 +Status: Draft + +1. Overview + + Rendezvous single onion services are an alternative design for single onion + services, which trade service-side location privacy for improved + performance, reliability, and scalability. + + Rendezvous single onion services have a .onion address identical to any + other onion service. The descriptor contains the same information as the + existing double onion (hidden) service descriptors. The introduction point + and rendezvous protocols occur as in double onion services, with one + modification: one-hop connections are made from the onion server to the + introduction and rendezvous points. + + This proposal is a revision of the unnumbered proposal Direct Onion + Services: Fast-but-not-hidden services by Roger Dingledine, and George + Kadianakis at + https://lists.torproject.org/pipermail/tor-dev/2015-April/008625.html + + It incorporates much of the discussion around hidden services since April + 2015, including content from Single Onion Services (Proposal #252) by John + Brooks, Paul Syverson, and Roger Dingledine. + +2. Motivation + + Rendezvous single onion services are best used by sites which: + * 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 + + Rendezvous single onion services have a few benefits over double onion + services: + + * Connection latency is lower, as one-hop circuits are built to the + introduction and rendezvous points, rather than three-hop circuits + * Stream latency is reduced on a four-hop circuit + * Less Tor network capacity is consumed by the service, as there are + fewer hops (4 rather than 6) between the client and server via the + rendezvous point + + Rendezvous single onion services have a few benefits over single onion + services: + + * A rendezvous single onion service can load-balance over multiple + rendezvous backends (see proposal #255) + * A rendezvous single onion service doesn't need an accessible ORPort + (it works behind a NAT, and in server enclaves that only allow + outward connections) + * A rendezvous single onion service is compatible with existing tor + clients, hidden service directories, introduction points, and + rendezvous points + + Rendezvous single onion services have a few drawbacks over single onion + services: + + * 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 + + It should also be noted that, while single onion services receive many + incoming connections from different relays, rendezvous single onion + services make many outgoing connections to different relays. This should + be taken into account when planning the connection capacity of the + infrastructure supporting the onion service. + + Rendezvous single onion services are not location hidden on the service + side, but clients retain all of the benefits and privacy of onion + services. (The rationale for the 'single' and 'double' nomenclature is + described in section 7.4 of proposal #252.) + + We believe that it is important for the Tor community to be aware of the + alternative single onion service designs, so that we can reach consensus + on the features and tradeoffs of each design. However, we recognise that + each additional flavour of onion service splits the anonymity set of onion + service users. Therefore, it may be best for user anonymity that not all + designs are adopted, or that mitigations are implemented along with each + additional flavour. (See sections 8 & 9 for a further discussion.) + +3. Onion descriptors + + The rendezvous single onion descriptor format is identical to the double + onion descriptor format. + +4. Reaching a rendezvous single onion service as a client + + Clients reach rendezvous single onion services in an identical fashion + to double onion services. The rendezvous design means that clients do not + know whether they are talking to a double or rendezvous single onion + service, unless that service tells them. (This may be a security issue.) + + However, the use of a four-hop path between client and rendezvous single + onion service may be statistically distinguishable. (See section 8 for + 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 + the client and endpoint is four-hop.) + +5. Publishing a rendezvous single onion service + + To act as a rendezvous single onion service, a tor instance (or cooperating + 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 + onion address. + * Perform the rendezvous protocol in the same manner as a double + onion service, but make the intro and rendezvous connections one-hop. + (This may allow intro and rendezvous points to block the service.) + +5.1. Configuration options + +5.1.1 RendezvousSingleOnionServiceNonAnonymousServer + + The tor instance operating a rendezvous single onion service must make + one-hop circuits to the introduction and rendezvous points: + + RendezvousSingleOnionServiceNonAnonymousServer 0|1 + If set, make one-hop circuits between the Rendezvous Single Onion + Service server, and the introduction and rendezvous points. This + option makes every onion service instance hosted by this tor instance + 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 + a startup warning message to operators of the onion service if this feature + is enabled. + [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 + (double onion) services and rendezvous single onion services on the same + tor instance. This is considered a feature, as it prevents hidden services + from being discovered via rendezvous single onion services on the same tor + instance. + +5.1.2 Recommended Additional Options: Correctness + + Based on the experiences of Tor2Web with one-hop paths, operators should + consider using the following options with every rendezvous single onion + service, and every single onion service: + + UseEntryGuards 0 + One-hop paths do not use entry guards. This also deactivates the entry + guard pathbias code, which is not compatible with one-hop paths. Entry + guards are a security measure against Sybil attacks. Unfortunately, + they also act as the bottleneck of busy onion services and overload + those Tor relays. + + LearnCircuitBuildTimeout 0 + Learning circuit build timeouts is incompatible with one-hop paths. + It also creates additional, unnecessary connections. + + Perhaps these options should be set automatically on (rendezvous) single + onion services. Tor2Web sets these options automatically: + UseEntryGuards 0 + LearnCircuitBuildTimeout 0 + +5.1.3 Recommended Additional Options: Performance + + LongLivedPorts + The default LongLivedPorts setting creates additional, unnecessary + connections. This specifies no long-lived ports (the empty list). + + PredictedPortsRelevanceTime 0 seconds + The default PredictedPortsRelevanceTime setting creates additional, + unnecessary connections. + + High-churn / quick-failover RSOS using descriptor competition strategies + should consider setting the following option: + + RendPostPeriod 600 seconds + Refresh onion service descriptors, choosing an interval between + 0 and 2*RendPostPeriod. Tor also posts descriptors on bootstrap, and + when they change. + (Strictly, 30 seconds after they first change, for descriptor + stability.) + + XX - Reduce the minimum RendPostPeriod for RSOS to 1 minute? + XX - Make the initial post 30 + rand(1*rendpostperiod) ? + (Avoid thundering herd, but don't hide startup time) + + However, we do NOT recommend setting the following option to 1, unless bug + #17359 is resolved so tor onion services can bootstrap without predicted + circuits. + + __DisablePredictedCircuits 0 + This option disables all predicted circuits. It is equivalent to: + LearnCircuitBuildTimeout 0 + LongLivedPorts + PredictedPortsRelevanceTime 0 seconds + And turning off hidden service server preemptive circuits, which is + currently unimplemented (#17360) + +5.1.3 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 + default, rendezvous single onion service operators should set: + + XX - George says we don't allow operators to run HS/Relay any more, + or that we warn them. + + SocksPort 0 + Disallow connections from client applications to the tor network + via this tor instance. + + ClientOnly 1 + Even if the defaults file configures this instance to be a relay, + never relay any traffic or serve any descriptors. + +5.2. Publishing descriptors + + A single onion service must publish descriptors in the same manner as any + onion service, as defined by rend-spec. + +5.3. Authorization + + Client authorization for a rendezvous single onion service is possible via + the same methods used for double onion services. + +6. Related Proposals, Tools, and Features + +6.1. Load balancing + + High capacity services can distribute load and implement failover by: + * running multiple instances that publish to the same onion service + directories, + * publishing descriptors containing multiple introduction points + (OnionBalance), + * publishing different introduction points to different onion service + directories (OnionBalance upcoming(?) feature), + * handing off rendezvous to a different tor instance via control port + messages (proposal #255), + or by a combination of these methods. + +6.2. Ephemeral single onion services (ADD_ONION) + + The ADD_ONION control port command could be extended to support ephemerally + configured rendezvous single onion services. Given that + RendezvousSingleOnionServiceNonAnonymousServer modifies the behaviour of + all onion services on a tor instance, if it is set, any ephemerally + configured onion service should become a rendezvous single onion service. + +6.3. Proposal 224 ("Next-Generation Hidden Services") + + This proposal is compatible with proposal 224, with onion services + acting just like a next-generation hidden service, but making one-hop + paths to the introduction and rendezvous points. + +6.4. Proposal 246 ("Merging Hidden Service Directories and Intro Points") + + This proposal is compatible with proposal 246. The onion service will + publish its descriptor to the introduction points in the same manner as any + other onion service. Clients will use the merged hidden service directory + and introduction point just as they do for other onion services. + +6.5. Proposal 252 ("Single Onion Services") + + This proposal is compatible with proposal 252. The onion service will + publish its descriptor to the introduction points in the same manner as any + other onion service. Clients can then choose to extend to the single onion + 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 + extend. This is useful for the transition period where not all clients + support single onion services. + +6.5. 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 + service. Controllers can then choose to handoff the rendezvous point + connection to another tor instance, which should also be configured + as a rendezvous single onion service. + +7. Considerations + +7.1 Modifying RendezvousSingleOnionServiceNonAnonymousServer at runtime + + Implementations should not reuse introduction points or introduction point + circuits if the value of RendezvousSingleOnionServiceNonAnonymousServer is + different than it was when the introduction point was selected. This is + because these circuits will have an undesirable length. + + There is specific code in tor that preserves introduction points on a HUP, + if RendezvousSingleOnionServiceNonAnonymousServer has changed, all circuits + should be closed, and all introduction points must be discarded. + +7.2 Delaying connection expiry + + Tor clients typically expire connections much faster than tor relays + [citation needed]. + + (Rendezvous) single onion service operators may find that keeping + connections open saves on connection latency. However, it may also place an + additional load on the service. (This could be implemented by increasing the + configured connection expiry time.) + +7.3. (No) Benefit to also running a Tor relay + + In tor Trac ticket #8742, running a relay and hidden onion service on the + same tor instance was disabled for security reasons. While there may be + benefits to running a relay on the same instance as a rendezvous single + onion service (existing connections mean lower latency, it helps the tor + network overall), a security analysis of this configuration has not yet + been performed. In addition, a potential drawback is overloading a busy + single onion service. + +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. + +8. Security Implications + +8.1 Splitting the Anonymity Set + + Each additional flavour of onion service, and each additional externally + visible onion service feature, provides oportunities for fingerprinting. + + Also, each additional type of onion service shrinks the anonymity set for + users of double onion (hidden) services who require server location + anonymity. These users benefit from the cover provided by current users of + onion services, who use them for client anonymity, self-authentication, + NAT-punching, or other benefits. + + For this reason, features that shrink the double onion service anonymity + set should be carefully considered. The benefits and drawbacks of + additional features also often depend on a particular threat model. + + It may be that a significant number of users and sites adopt (rendezvous) + 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. + +8.2 Hidden Service Designs can potentially be more secure + + As a side-effect, by optimizing for performance in this feature, it + allows us to lean more heavily towards security decisions for + regular onion services. + +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 -- + if *some* .onion addresses are easy to track down, are we encouraging + adversaries to attack all rendezvous points just in case? + +9. Further Work + +Further proposals or research could attempt to mitigate the anonymity-set +splitting described in section 8. Here are some initial ideas. + +9.1 Making Client Exit connections look like Client Onion Service Connections + + A mitigation to this fingerprinting is to make each (or some) exit + connections look like onion service connections. This provides cover for + particular types of onion service connections. Unfortunately, it is not + possible to make onion service connections look like exit connections, + as there are no suitable dummy servers to exit to on the Internet. + +9.1.1 Making Client Exit connections perform Descriptor Downloads + + (Some) exit connections could perform a dummy descriptor download. + (However, descriptors for recently accessed onion services are cached, so + dummy downloads should only be performed occasionally.) + + Exit connections already involve a four-hop "circuit" to the server + (including the connection between the exit and the server on the Internet). + The server on the Internet is not included in the consensus. Therefore, + this mitigation would effectively cover single onion services which are not + relays. + +9.1.2 Making Client Exit connections perform the Rendezvous Protocol + + (Some) exit connections could perform a dummy rendezvous protocol. + + Exit connections already involve a four-hop "circuit" to the server + (including the connection between the exit and the server on the Internet). + Therefore, this mitigation would effectively cover rendezvous single onion + services, as long as a dummy descriptor download was also performed + occasionally. + +9.1.3 Making Single Onion Service rendezvous points perform name resolution + + Currently, Exits perform DNS name resolution, and changing this behaviour + would cause unacceptable connection latency. Therefore, we could make + onion service connections look like exit connections by making the + rendezvous point do name resolution (that is, descriptor fetching), and, if + needed, the introduction part of the protocol. This could potentially + *reduce* the latency of single onion service connections, depending on the + length of the paths used by the rendezvous point. + + However, this change makes rendezvous points almost as powerful as Exits, + a careful security analysis will need to be performed before this is + implemented. + + There is also a design issue with rendezvous name resolution: a client + wants to leave resolution (descriptor download) to the RP, but it doesn't + know whether it can use the exit-like protocol with an RP until it has + downloaded the descriptor. This might mean that single onion services of + both flavours need a different address style or address namespace. We could + use .single.onion or something. (This would require an update to the HSDir + code.) + +9.2 Performing automated and common queries over onion services + + Tor could create cover traffic for a flavour of onion service by performing + automated or common queries via an onion service of that type. In addition, + onion service-based checks have security benefits over DNS-based checks. + See Genuine Onion, Syverson and Boyce, 2015, at + http://www.nrl.navy.mil/itd/chacs/syverson-genuine-onion-simple-fast-flexib… + + Here are some examples of automated queries that could be performed over + an onion service: + +9.2.1 torcheck over onion service + + torcheck ("Congratulations! This browser is configured to use Tor.") could + be retrieved from an onion service. + + Incidentally, this would resolve the exitmap issues in #17297, but it + would also fail to check that exit connections work, which is important for + many Tor Browser users. + +9.2.2 Tor Browser version checks over onion service + + Running tor browser version checks over an onion service seems to be an + excellent use-case for onion services. It would also have the Tor Project + "eating its own dogfood", that is, using onion services for its essential + services. + +9.2.3 Tor Browser downloads over onion service + + Running tor browser downloads over an onion service might require some work + on the onion service codebase to support high loads, load-balancing, and + failover. It is a good use case for a (rendezvous) single onion service, + as the traffic over the tor network is only slightly higher than for + Tor Browser downloads over tor. (4 hops for [R]SOS, 3 hops for Exit.) + +9.2.4 SSL Observatory submissions over onion service + + HTTPS certificates could be submitted to HTTPS Everywhere's SSL Observatory + over an onion service. + + 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. diff --git a/proposals/ideas/xxx-rend-single-onion.txt b/proposals/ideas/xxx-rend-single-onion.txt deleted file mode 100644 index d402618..0000000 --- a/proposals/ideas/xxx-rend-single-onion.txt +++ /dev/null @@ -1,460 +0,0 @@ -Filename: xxx-rend-single-onion.txt -Title: Rendezvous Single Onion Services -Author: Tim Wilson-Brown, John Brooks, Aaron Johnson, Rob Jansen, George Kadianakis, Paul Syverson, Roger Dingledine -Created: 2015-10-17 -Status: Draft - -1. Overview - - Rendezvous single onion services are an alternative design for single onion - services, which trade service-side location privacy for improved - performance, reliability, and scalability. - - Rendezvous single onion services have a .onion address identical to any - other onion service. The descriptor contains the same information as the - existing double onion (hidden) service descriptors. The introduction point - and rendezvous protocols occur as in double onion services, with one - modification: one-hop connections are made from the onion server to the - introduction and rendezvous points. - - This proposal is a revision of the unnumbered proposal Direct Onion - Services: Fast-but-not-hidden services by Roger Dingledine, and George - Kadianakis at - https://lists.torproject.org/pipermail/tor-dev/2015-April/008625.html - - It incorporates much of the discussion around hidden services since April - 2015, including content from Single Onion Services (Proposal #252) by John - Brooks, Paul Syverson, and Roger Dingledine. - -2. Motivation - - Rendezvous single onion services are best used by sites which: - * 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 - - Rendezvous single onion services have a few benefits over double onion - services: - - * Connection latency is lower, as one-hop circuits are built to the - introduction and rendezvous points, rather than three-hop circuits - * Stream latency is reduced on a four-hop circuit - * Less Tor network capacity is consumed by the service, as there are - fewer hops (4 rather than 6) between the client and server via the - rendezvous point - - Rendezvous single onion services have a few benefits over single onion - services: - - * A rendezvous single onion service can load-balance over multiple - rendezvous backends (see proposal #255) - * A rendezvous single onion service doesn't need an accessible ORPort - (it works behind a NAT, and in server enclaves that only allow - outward connections) - * A rendezvous single onion service is compatible with existing tor - clients, hidden service directories, introduction points, and - rendezvous points - - Rendezvous single onion services have a few drawbacks over single onion - services: - - * 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 - - It should also be noted that, while single onion services receive many - incoming connections from different relays, rendezvous single onion - services make many outgoing connections to different relays. This should - be taken into account when planning the connection capacity of the - infrastructure supporting the onion service. - - Rendezvous single onion services are not location hidden on the service - side, but clients retain all of the benefits and privacy of onion - services. (The rationale for the 'single' and 'double' nomenclature is - described in section 7.4 of proposal #252.) - - We believe that it is important for the Tor community to be aware of the - alternative single onion service designs, so that we can reach consensus - on the features and tradeoffs of each design. However, we recognise that - each additional flavour of onion service splits the anonymity set of onion - service users. Therefore, it may be best for user anonymity that not all - designs are adopted, or that mitigations are implemented along with each - additional flavour. (See sections 8 & 9 for a further discussion.) - -3. Onion descriptors - - The rendezvous single onion descriptor format is identical to the double - onion descriptor format. - -4. Reaching a rendezvous single onion service as a client - - Clients reach rendezvous single onion services in an identical fashion - to double onion services. The rendezvous design means that clients do not - know whether they are talking to a double or rendezvous single onion - service, unless that service tells them. (This may be a security issue.) - - However, the use of a four-hop path between client and rendezvous single - onion service may be statistically distinguishable. (See section 8 for - 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 - the client and endpoint is four-hop.) - -5. Publishing a rendezvous single onion service - - To act as a rendezvous single onion service, a tor instance (or cooperating - 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 - onion address. - * Perform the rendezvous protocol in the same manner as a double - onion service, but make the intro and rendezvous connections one-hop. - (This may allow intro and rendezvous points to block the service.) - -5.1. Configuration options - -5.1.1 RendezvousSingleOnionServiceNonAnonymousServer - - The tor instance operating a rendezvous single onion service must make - one-hop circuits to the introduction and rendezvous points: - - RendezvousSingleOnionServiceNonAnonymousServer 0|1 - If set, make one-hop circuits between the Rendezvous Single Onion - Service server, and the introduction and rendezvous points. This - option makes every onion service instance hosted by this tor instance - 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 - a startup warning message to operators of the onion service if this feature - is enabled. - [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 - (double onion) services and rendezvous single onion services on the same - tor instance. This is considered a feature, as it prevents hidden services - from being discovered via rendezvous single onion services on the same tor - instance. - -5.1.2 Recommended Additional Options: Correctness - - Based on the experiences of Tor2Web with one-hop paths, operators should - consider using the following options with every rendezvous single onion - service, and every single onion service: - - UseEntryGuards 0 - One-hop paths do not use entry guards. This also deactivates the entry - guard pathbias code, which is not compatible with one-hop paths. Entry - guards are a security measure against Sybil attacks. Unfortunately, - they also act as the bottleneck of busy onion services and overload - those Tor relays. - - LearnCircuitBuildTimeout 0 - Learning circuit build timeouts is incompatible with one-hop paths. - It also creates additional, unnecessary connections. - - Perhaps these options should be set automatically on (rendezvous) single - onion services. Tor2Web sets these options automatically: - UseEntryGuards 0 - LearnCircuitBuildTimeout 0 - -5.1.3 Recommended Additional Options: Performance - - LongLivedPorts - The default LongLivedPorts setting creates additional, unnecessary - connections. This specifies no long-lived ports (the empty list). - - PredictedPortsRelevanceTime 0 seconds - The default PredictedPortsRelevanceTime setting creates additional, - unnecessary connections. - - High-churn / quick-failover RSOS using descriptor competition strategies - should consider setting the following option: - - RendPostPeriod 600 seconds - Refresh onion service descriptors, choosing an interval between - 0 and 2*RendPostPeriod. Tor also posts descriptors on bootstrap, and - when they change. - (Strictly, 30 seconds after they first change, for descriptor - stability.) - - XX - Reduce the minimum RendPostPeriod for RSOS to 1 minute? - XX - Make the initial post 30 + rand(1*rendpostperiod) ? - (Avoid thundering herd, but don't hide startup time) - - However, we do NOT recommend setting the following option to 1, unless bug - #17359 is resolved so tor onion services can bootstrap without predicted - circuits. - - __DisablePredictedCircuits 0 - This option disables all predicted circuits. It is equivalent to: - LearnCircuitBuildTimeout 0 - LongLivedPorts - PredictedPortsRelevanceTime 0 seconds - And turning off hidden service server preemptive circuits, which is - currently unimplemented (#17360) - -5.1.3 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 - default, rendezvous single onion service operators should set: - - XX - George says we don't allow operators to run HS/Relay any more, - or that we warn them. - - SocksPort 0 - Disallow connections from client applications to the tor network - via this tor instance. - - ClientOnly 1 - Even if the defaults file configures this instance to be a relay, - never relay any traffic or serve any descriptors. - -5.2. Publishing descriptors - - A single onion service must publish descriptors in the same manner as any - onion service, as defined by rend-spec. - -5.3. Authorization - - Client authorization for a rendezvous single onion service is possible via - the same methods used for double onion services. - -6. Related Proposals, Tools, and Features - -6.1. Load balancing - - High capacity services can distribute load and implement failover by: - * running multiple instances that publish to the same onion service - directories, - * publishing descriptors containing multiple introduction points - (OnionBalance), - * publishing different introduction points to different onion service - directories (OnionBalance upcoming(?) feature), - * handing off rendezvous to a different tor instance via control port - messages (proposal #255), - or by a combination of these methods. - -6.2. Ephemeral single onion services (ADD_ONION) - - The ADD_ONION control port command could be extended to support ephemerally - configured rendezvous single onion services. Given that - RendezvousSingleOnionServiceNonAnonymousServer modifies the behaviour of - all onion services on a tor instance, if it is set, any ephemerally - configured onion service should become a rendezvous single onion service. - -6.3. Proposal 224 ("Next-Generation Hidden Services") - - This proposal is compatible with proposal 224, with onion services - acting just like a next-generation hidden service, but making one-hop - paths to the introduction and rendezvous points. - -6.4. Proposal 246 ("Merging Hidden Service Directories and Intro Points") - - This proposal is compatible with proposal 246. The onion service will - publish its descriptor to the introduction points in the same manner as any - other onion service. Clients will use the merged hidden service directory - and introduction point just as they do for other onion services. - -6.5. Proposal 252 ("Single Onion Services") - - This proposal is compatible with proposal 252. The onion service will - publish its descriptor to the introduction points in the same manner as any - other onion service. Clients can then choose to extend to the single onion - 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 - extend. This is useful for the transition period where not all clients - support single onion services. - -6.5. 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 - service. Controllers can then choose to handoff the rendezvous point - connection to another tor instance, which should also be configured - as a rendezvous single onion service. - -7. Considerations - -7.1 Modifying RendezvousSingleOnionServiceNonAnonymousServer at runtime - - Implementations should not reuse introduction points or introduction point - circuits if the value of RendezvousSingleOnionServiceNonAnonymousServer is - different than it was when the introduction point was selected. This is - because these circuits will have an undesirable length. - - There is specific code in tor that preserves introduction points on a HUP, - if RendezvousSingleOnionServiceNonAnonymousServer has changed, all circuits - should be closed, and all introduction points must be discarded. - -7.2 Delaying connection expiry - - Tor clients typically expire connections much faster than tor relays - [citation needed]. - - (Rendezvous) single onion service operators may find that keeping - connections open saves on connection latency. However, it may also place an - additional load on the service. (This could be implemented by increasing the - configured connection expiry time.) - -7.3. (No) Benefit to also running a Tor relay - - In tor Trac ticket #8742, running a relay and hidden onion service on the - same tor instance was disabled for security reasons. While there may be - benefits to running a relay on the same instance as a rendezvous single - onion service (existing connections mean lower latency, it helps the tor - network overall), a security analysis of this configuration has not yet - been performed. In addition, a potential drawback is overloading a busy - single onion service. - -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. - -8. Security Implications - -8.1 Splitting the Anonymity Set - - Each additional flavour of onion service, and each additional externally - visible onion service feature, provides oportunities for fingerprinting. - - Also, each additional type of onion service shrinks the anonymity set for - users of double onion (hidden) services who require server location - anonymity. These users benefit from the cover provided by current users of - onion services, who use them for client anonymity, self-authentication, - NAT-punching, or other benefits. - - For this reason, features that shrink the double onion service anonymity - set should be carefully considered. The benefits and drawbacks of - additional features also often depend on a particular threat model. - - It may be that a significant number of users and sites adopt (rendezvous) - 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. - -8.2 Hidden Service Designs can potentially be more secure - - As a side-effect, by optimizing for performance in this feature, it - allows us to lean more heavily towards security decisions for - regular onion services. - -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 -- - if *some* .onion addresses are easy to track down, are we encouraging - adversaries to attack all rendezvous points just in case? - -9. Further Work - -Further proposals or research could attempt to mitigate the anonymity-set -splitting described in section 8. Here are some initial ideas. - -9.1 Making Client Exit connections look like Client Onion Service Connections - - A mitigation to this fingerprinting is to make each (or some) exit - connections look like onion service connections. This provides cover for - particular types of onion service connections. Unfortunately, it is not - possible to make onion service connections look like exit connections, - as there are no suitable dummy servers to exit to on the Internet. - -9.1.1 Making Client Exit connections perform Descriptor Downloads - - (Some) exit connections could perform a dummy descriptor download. - (However, descriptors for recently accessed onion services are cached, so - dummy downloads should only be performed occasionally.) - - Exit connections already involve a four-hop "circuit" to the server - (including the connection between the exit and the server on the Internet). - The server on the Internet is not included in the consensus. Therefore, - this mitigation would effectively cover single onion services which are not - relays. - -9.1.2 Making Client Exit connections perform the Rendezvous Protocol - - (Some) exit connections could perform a dummy rendezvous protocol. - - Exit connections already involve a four-hop "circuit" to the server - (including the connection between the exit and the server on the Internet). - Therefore, this mitigation would effectively cover rendezvous single onion - services, as long as a dummy descriptor download was also performed - occasionally. - -9.1.3 Making Single Onion Service rendezvous points perform name resolution - - Currently, Exits perform DNS name resolution, and changing this behaviour - would cause unacceptable connection latency. Therefore, we could make - onion service connections look like exit connections by making the - rendezvous point do name resolution (that is, descriptor fetching), and, if - needed, the introduction part of the protocol. This could potentially - *reduce* the latency of single onion service connections, depending on the - length of the paths used by the rendezvous point. - - However, this change makes rendezvous points almost as powerful as Exits, - a careful security analysis will need to be performed before this is - implemented. - - There is also a design issue with rendezvous name resolution: a client - wants to leave resolution (descriptor download) to the RP, but it doesn't - know whether it can use the exit-like protocol with an RP until it has - downloaded the descriptor. This might mean that single onion services of - both flavours need a different address style or address namespace. We could - use .single.onion or something. (This would require an update to the HSDir - code.) - -9.2 Performing automated and common queries over onion services - - Tor could create cover traffic for a flavour of onion service by performing - automated or common queries via an onion service of that type. In addition, - onion service-based checks have security benefits over DNS-based checks. - See Genuine Onion, Syverson and Boyce, 2015, at - http://www.nrl.navy.mil/itd/chacs/syverson-genuine-onion-simple-fast-flexib… - - Here are some examples of automated queries that could be performed over - an onion service: - -9.2.1 torcheck over onion service - - torcheck ("Congratulations! This browser is configured to use Tor.") could - be retrieved from an onion service. - - Incidentally, this would resolve the exitmap issues in #17297, but it - would also fail to check that exit connections work, which is important for - many Tor Browser users. - -9.2.2 Tor Browser version checks over onion service - - Running tor browser version checks over an onion service seems to be an - excellent use-case for onion services. It would also have the Tor Project - "eating its own dogfood", that is, using onion services for its essential - services. - -9.2.3 Tor Browser downloads over onion service - - Running tor browser downloads over an onion service might require some work - on the onion service codebase to support high loads, load-balancing, and - failover. It is a good use case for a (rendezvous) single onion service, - as the traffic over the tor network is only slightly higher than for - Tor Browser downloads over tor. (4 hops for [R]SOS, 3 hops for Exit.) - -9.2.4 SSL Observatory submissions over onion service - - HTTPS certificates could be submitted to HTTPS Everywhere's SSL Observatory - over an onion service. - - 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