- tor-commits - lists.torproject.org

[tor/maint-0.2.1] Fix remotely triggerable assert during ip decryption
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit d5161ab895b9c14a66a08fb38521dd12c0772a97 Author: Dan Rosenberg <dan.j.rosenberg(a)gmail.com> Date: Sun Nov 6 17:23:14 2011 +0100 Fix remotely triggerable assert during ip decryption Fixes bug 4410. --- src/or/routerparse.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/or/routerparse.c b/src/or/routerparse.c index 19f9e38..843fc79 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3858,6 +3858,11 @@ rend_decrypt_introduction_points(char **ipos_decrypted, crypto_cipher_env_t *cipher; char *dec; int declen; + if (ipos_encrypted_size < CIPHER_IV_LEN + 2) { + log_warn(LD_REND, "Size of encrypted introduction points is too " + "small."); + return -1; + } dec = tor_malloc_zero(ipos_encrypted_size - CIPHER_IV_LEN - 1); cipher = crypto_create_init_cipher(descriptor_cookie, 0); declen = crypto_cipher_decrypt_with_iv(cipher, dec,

1 0

[tor/maint-0.2.1] Add a changes file for 4410
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit be6928d6e78a47800a96962403efff753ad70e84 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Sun Nov 6 17:24:09 2011 +0100 Add a changes file for 4410 --- changes/bug4410 | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/changes/bug4410 b/changes/bug4410 new file mode 100644 index 0000000..f42893a --- /dev/null +++ b/changes/bug4410 @@ -0,0 +1,5 @@ + o Major bugfixes: + - Correctly sanity-check that we don't underflow on a memory allocation + for introduction point decryption. Bug discovered by Dan Rosenberg. + Fixes bug 4410; bugfix on 0.2.1.5-alpha. +

1 0

[torspec/master] Add proposals/189-authorize-cell.txt.
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 067ba228365a0262e08c0af9a8da16d5d35e1a62 Author: George Kadianakis <desnacked(a)gmail.com> Date: Fri Nov 4 18:38:51 2011 +0100 Add proposals/189-authorize-cell.txt. --- proposals/189-authorize-cell.txt | 122 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 122 insertions(+), 0 deletions(-) diff --git a/proposals/189-authorize-cell.txt b/proposals/189-authorize-cell.txt new file mode 100644 index 0000000..10b45a2 --- /dev/null +++ b/proposals/189-authorize-cell.txt @@ -0,0 +1,122 @@ +Filename: 189-authorize-cell.txt +Title: AUTHORIZE and AUTHORIZED cells +Author: George Kadianakis +Created: 04 Nov 2011 +Status: Open + +1. Overview + + Proposal 187 introduced the concept of the AUTHORIZE cell, a cell + whose purpose is to make Tor bridges resistant to scanning attacks. + + This is achieved by having the bridge and the client share a secret + out-of-band and then use AUTHORIZE cells to validate that the + client indeed knows that secret before proceeding with the Tor + protocol. + + This proposal specifies the format of the AUTHORIZE cell and also + introduces the AUTHORIZED cell, a way for bridges to announce to + clients that the authorization process is complete and successful. + +2. Motivation + + AUTHORIZE cells should be able to perform a variety of + authorization protocols based on a variety of shared secrets. This + forces the AUTHORIZE cell to have a dynamic format based on the + authorization method used. + + AUTHORIZED cells are used by bridges to signal the end of a + successful bridge client authorization and the beginning of the + actual link handshake. AUTHORIZED cells have no other use and for + this reason their format is very simple. + + Both AUTHORIZE and AUTHORIZED cells are to be used under censorship + conditions and they should look innocuous to any adversary capable + of monitoring network traffic. + + As an attack example, an adversary could passively monitor the + traffic of a bridge host, looking at the packets directly after the + TLS handshake and trying to deduce from their packet size if they + are AUTHORIZE and AUTHORIZED cells. For this reason, AUTHORIZE and + AUTHORIZED cells are padded with a random amount of padding before + sending. + +3. Design + +3.1. AUTHORIZE cell + + The AUTHORIZE cell is a variable-sized cell. + + The generic AUTHORIZE cell format is: + + AuthMethod [1 octet] + MethodFields [...] + PadLen [2 octets] + Padding ['PadLen' octets] + + where: + + 'AuthMethod', is the authorization method to be used. + + 'MethodFields', is dependent on the authorization Method used. It's + a meta-field hosting an arbitrary amount of fields. + + 'PadLen', specifies the amount of padding in octets. + + 'Padding', is 'PadLen' octets of random content. + +3.2. AUTHORIZED cell format + + The AUTHORIZED cell is a variable-sized cell. + + The AUTHORIZED cell format is: + + 'AuthMethod' [1 octet] + 'PadLen' [2 octets] + 'Padding' ['PadLen' octets] + + where all fields have the same meaning as in section 3.1. + +3.3. Cell parsing + + Implementations MUST ignore the contents of 'Padding'. + + Implementations MUST reject an AUTHORIZE or AUTHORIZED cell where + the 'Padding' field is not 'PadLen' octets long. + + Implementations MUST reject an AUTHORIZE cell with an 'AuthMethod' + they don't recognize. + +4. Discussion + +4.1. Why not let the pluggable transports do the padding, like they + are supposed to do for the rest of the Tor protocol? + + The arguments of section "Alternative design: Just use pluggable + transports" of proposal 187, apply here as well: + + All bridges who use client authorization will also need camouflaged + AUTHORIZE/AUTHORIZED cell. + +4.2. How should multiple round-trip authorization protocols be handled? + + Protocols that require multiple round-trips between the client and + the bridge should use AUTHORIZE cells for communication. + + The format of the AUTHORIZE cell is flexible enough to support + messages from the client to the bridge and the inverse. + + In the end of a successful multiple round-trip protocol, an + AUTHORIZED cell must be issued from the bridge to the client. + +4.3. AUTHORIZED seems useless. Why not use VPADDING instead? + + As noted in proposal 187, the Tor protocol uses VPADDING cells for + padding; any other use of VPADDING makes the Tor protocol kludgy. + + In the future, and in the example case of a v3 handshake, a client + can optimistically send a VERSIONS cell along with the final + AUTHORIZE cell of an authorization protocol. That allows the + bridge, in the case of successful authorization, to also process + the VERSIONS cell and begin the v3 handshake promptly. +

1 0

[torspec/master] Now add proposals/190-password-bridge-authorization.txt.
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 4aba6f4a27638cd9fed82124f70c640a054003a1 Author: George Kadianakis <desnacked(a)gmail.com> Date: Fri Nov 4 18:39:00 2011 +0100 Now add proposals/190-password-bridge-authorization.txt. --- proposals/190-password-bridge-authorization.txt | 156 +++++++++++++++++++++++ 1 files changed, 156 insertions(+), 0 deletions(-) diff --git a/proposals/190-password-bridge-authorization.txt b/proposals/190-password-bridge-authorization.txt new file mode 100644 index 0000000..36c8c35 --- /dev/null +++ b/proposals/190-password-bridge-authorization.txt @@ -0,0 +1,156 @@ +Filename: 190-password-bridge-authorization.txt +Title: Password-based Bridge Client Authorization +Author: George Kadianakis +Created: 04 Nov 2011 +Status: Open + +1. Overview + + Proposals 187 and 189 introduced the AUTHORIZE and AUTHORIZED cells. + Their purpose is to make bridge relays scanning resistant against + censoring adversaries capable of probing hosts to observe whether + they speak the Tor protocol. + + This proposal specifies a bridge client authorization scheme based + on a shared password between the bridge user and bridge operator. + +2. Motivation + + A proper bridge client authorization scheme should: + + - request information from a client that only an authorized bridge + client would know. + + - ensure that the shared secret sent by the bridge client during + the authorization can only be read and validated by the proper + bridge relay. This is important since the v3 link handshake which + authenticates the bridge to the client is carried out *after* the + bridge client authorization, which means that when the AUTHORIZE + cell is sent, the client might be actually speaking to a Man In + The Middle. + + The bridge client authorization scheme presented in this proposal + is based on a shared password and attempts to satisfy both of the + above requirements. + +3. Design + + If the AuthMethod of an AUTHORIZE cell is '0x1', the client wants + to become authorized using a shared secret based on a password. + + The short name of this authorization scheme is 'BRIDGE_AUTH_PSK'. + +3.1. Notation + + '||', denotes concatenation. + + 'HMAC(k, m)', is the Hash-based Message Authentication Code of + message 'm' using 'k' as the secret key. + + 'H(m)', is a cryptographic hash function applied on a message 'm'. + + 'HASH_LEN', is the output size of the hash function 'H'. + +3.2. Shared secret format + + A bridge client and a bridge relay willing to use this + authorization scheme, should have already exchanged out-of-band + (for example, during the bridge credentials exchange) a shared + password. + + In this case, the shared secret of this scheme becomes: + + shared_secret = H( H(bridge_identity_key) || ":" || password) + + where: + + 'bridge_identity_key', is the PKCS#1 ASN1 encoding of the bridge's + public identity key. + + '":"', is the colon character (0x3a in UTF-8). + + 'password', is the bridge password. + +3.3. Password-based authorization AUTHORIZE cell format + + In password-based authorization, the MethodFields field of the + AUTHORIZE cell becomes: + + 'HMAC(shared_secret, tls_cert)' [HASH_LEN octets] + + where: + + 'HMAC(shared_secret, tls_cert), is the HMAC construction of the TLS + certificate of the bridge relay, using the shared secret of section + 3.2 as the secret key. + +3.4. Password-based authorization notes + + Bridge implementations MUST reject clients who provide malformed + AUTHORIZE cells or HMAC values that do not verify the appropriate + TLS certificate. + + Bridge implementations SHOULD provide an easy way to create and + change the bridge shared secret. + +3.5. Security arguments + + An adversary who does not know the 'shared_secret' of a bridge + cannot construct an HMAC that verifies its TLS certificate when + used with the correct 'shared_secret'. + + An adversary who attempts to MITM the TLS connection of a bridge + user to steal the 'shared_secret' will instead steal an HMAC value + created by the 'tls_cert' of the TLS certificate that the attacker + used to MITM the TLS connection. Replaying that 'shared_secret' + value to the actual bridge will fail to verify the correct + 'tls_cert'. + + The two above paragraphs resolve the requirements of the + 'Motivation' section. + + Furthermore, an adversary who compromises a bridge, steals the + shared secret and attempts to replay it to other bridges of the + same bridge operator will fail since each shared secret has a + digest of the bridge's identity key baked in it. + + The bridge's identity key digest also serves as a salt to counter + rainbow table precomputation attacks. + +4. Tor implementation + + The Tor implementation of the above scheme uses SHA256 as the hash + function 'H'. + + SHA256 also makes HASH_LEN equal to 32. + +5. Discussion + +5.1. Do we need more authorization schemes? + + Probably yes. + + The centuries-old problem with passwords is that humans can't get + their passwords right. + + To avoid problems associated with the human condition, schemes + based on public key cryptography and certificates can be used. A + public and well tested protocol that can be used as the basis of a + future authorization scheme is the SSH "publickey" authorization + protocol. + +5.2. What should actually happen when a bridge rejects an AUTHORIZE + cell? + + When a bridge detects a badly formed or malicious AUTHORIZE cell, + it should assume that the other side is an adversary scanning for + bridges. The bridge should then act accordingly to avoid detection. + + This proposal does not try to specify how a bridge can avoid + detection by an adversary. + +6. Acknowledgements + + Without Nick Mathewson and Robert Ransom this proposal would + actually be specifying a useless and broken authentication scheme. + Thanks!

1 0

[torspec/master] update proposal index
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit eb2e2e7dcdeb0e4bf35aa710388498ad21bd39a9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Nov 7 10:36:06 2011 -0500 update proposal index --- proposals/000-index.txt | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 65bb211..c270a26 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -109,6 +109,8 @@ Proposals by number: 186 Multiple addresses for one OR or bridge [DRAFT] 187 Reserve a cell type to allow client authorization [OPEN] 188 Bridge Guards and other anti-enumeration defenses [OPEN] +189 AUTHORIZE and AUTHORIZED cells [OPEN] +190 Password-based Bridge Client Authorization [OPEN] Proposals by status: @@ -141,6 +143,8 @@ Proposals by status: 185 Directory caches without DirPort 187 Reserve a cell type to allow client authorization [for 0.2.3.x] 188 Bridge Guards and other anti-enumeration defenses + 189 AUTHORIZE and AUTHORIZED cells + 190 Password-based Bridge Client Authorization ACCEPTED: 110 Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha] 117 IPv6 exits [for 0.2.3.x]

1 0

[metrics-web/master] Yes, we already know that we have a database problem.
by karsten＠torproject.org 07 Nov '11

07 Nov '11

commit 14bf37488c5774f87adac9762bd35900662769c9 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Nov 7 15:44:36 2011 +0100 Yes, we already know that we have a database problem. --- src/org/torproject/ernie/web/RelayServlet.java | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-) diff --git a/src/org/torproject/ernie/web/RelayServlet.java b/src/org/torproject/ernie/web/RelayServlet.java index 037a1e4..64f343d 100644 --- a/src/org/torproject/ernie/web/RelayServlet.java +++ b/src/org/torproject/ernie/web/RelayServlet.java @@ -184,7 +184,10 @@ public class RelayServlet extends HttpServlet { out.println("Warning: We " + "experienced an unknown database problem while looking up " + "the relay with fingerprint starting with " - + fingerprintParameter + ". If this problem persists, please " + + fingerprintParameter + ". Unfortunately, this is very " + + "likely a <a href=\"https://trac.torproject.org/projects/" + + "tor/ticket/4406\">known problem</a>. If you don't think " + + "these problems are related, please " + "<a href=\"mailto:tor-assistants@torproject.org\">let us " + "know</a>!\n"); writeFooter(out); @@ -279,7 +282,10 @@ public class RelayServlet extends HttpServlet { + "experienced an unknown database problem while looking up " + "the relay with fingerprint " + (fingerprintParameter.length() < 40 ? "starting with " : "") - + fingerprintParameter + ". If this problem persists, please " + + fingerprintParameter + ". Unfortunately, this is very likely " + + "a <a href=\"https://trac.torproject.org/projects/tor/ticket" + + "/4406\">known problem</a>. If you don't think these " + + "problems are related, please " + "<a href=\"mailto:tor-assistants@torproject.org\">let us " + "know</a>!\n"); writeFooter(out); @@ -330,8 +336,10 @@ public class RelayServlet extends HttpServlet { } catch (SQLException e) { out.write(" Warning: " + "Internal server error when looking up descriptor. The " - + "query was '" + query + "'. If this problem persists, " - + "please " + + "query was '" + query + "'. Unfortunately, this is very " + + "likely a <a href=\"https://trac.torproject.org/projects/" + + "tor/ticket/4406\">known problem</a>. If you don't think " + + "these problems are related, please " + "<a href=\"mailto:tor-assistants@torproject.org\">let us " + "know</a>!\n"); writeFooter(out);

1 0

[metrics-web/master] Require $ prefix for fingerprints on relay-search.html.
by karsten＠torproject.org 07 Nov '11

07 Nov '11

commit 4316492e187a1f36ddc5eec2a377ab1674ad9d38 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Nov 7 15:24:15 2011 +0100 Require $ prefix for fingerprints on relay-search.html. Implements #4314 which suggests accepting fingerprints with the $ prefix, but also requires the $ prefix for all fingerprints in order to distinguish them from nicknames. Before this change we had to treat some search parameters as "fingerprint or nickname" which complicated the database query string a lot. --- .../torproject/ernie/web/RelaySearchServlet.java | 66 ++++--------------- web/WEB-INF/relay-search.jsp | 9 ++- 2 files changed, 19 insertions(+), 56 deletions(-) diff --git a/src/org/torproject/ernie/web/RelaySearchServlet.java b/src/org/torproject/ernie/web/RelaySearchServlet.java index 4cb9694..05be5e8 100644 --- a/src/org/torproject/ernie/web/RelaySearchServlet.java +++ b/src/org/torproject/ernie/web/RelaySearchServlet.java @@ -23,21 +23,21 @@ import org.apache.commons.codec.binary.*; * - gabelmoo * - gabelmoo 2010-09 * - gabelmoo 2010-09-18 - * - gabelmoo F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 + * - gabelmoo $F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 * - gabelmoo 80.190.246 - * - gabelmoo F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 80.190.246 + * - gabelmoo $F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 80.190.246 * - 5898549205 dc737cc9dca16af6 79.212.74.45 * - 5898549205 dc737cc9dca16af6 * - 80.190.246.100 - * - F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 - * - F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 80.190.246 + * - $F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 + * - $F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 80.190.246 * - 58985492 * - 58985492 79.212.74.45 */ public class RelaySearchServlet extends HttpServlet { - private Pattern alphaNumDotDashSpacePattern = - Pattern.compile("[A-Za-z0-9\\.\\- ]+"); + private Pattern alphaNumDotDashDollarSpacePattern = + Pattern.compile("[A-Za-z0-9\\.\\-$ ]+"); private Pattern numPattern = Pattern.compile("[0-9]+"); @@ -97,7 +97,6 @@ public class RelaySearchServlet extends HttpServlet { String searchNickname = ""; String searchFingerprint = ""; String searchIPAddress = ""; - SortedSet<String> searchFingerprintOrNickname = new TreeSet<String>(); SortedSet<String> searchDays = new TreeSet<String>(); SortedSet<String> searchMonths = new TreeSet<String>(); SortedSet<Long> searchDayTimestamps = new TreeSet<Long>(); @@ -106,7 +105,8 @@ public class RelaySearchServlet extends HttpServlet { /* Only parse search parameter if it contains nothing else than * alphanumeric characters, dots, and spaces. */ - if (alphaNumDotDashSpacePattern.matcher(searchParameter).matches()) { + if (alphaNumDotDashDollarSpacePattern.matcher(searchParameter). + matches()) { SortedSet<String> searchTerms = new TreeSet<String>(); if (searchParameter.trim().contains(" ")) { String[] split = searchParameter.trim().split(" "); @@ -177,23 +177,16 @@ public class RelaySearchServlet extends HttpServlet { } } - /* If the search term contains between 8 and 19 hex characters, it - * could be either a nickname or a fingerprint. */ - else if (searchTerm.length() >= 8 && searchTerm.length() <= 19 && - hexPattern.matcher(searchTerm).matches()) { - searchFingerprintOrNickname.add(searchTerm); - validQuery = true; - } - - /* If the search term contains between 20 and 40 hex characters, - * it must be a fingerprint. */ - else if (searchTerm.length() >= 20 && searchTerm.length() <= 40 && - hexPattern.matcher(searchTerm).matches()) { + /* If the search term starts with a $ followed by 8 to 40 hex + * characters, it must be a fingerprint. */ + else if (searchTerm.length() >= 9 && searchTerm.length() <= 41 && + searchTerm.startsWith("$") && + hexPattern.matcher(searchTerm.substring(1)).matches()) { if (searchFingerprint.length() > 0) { validQuery = false; break; } - searchFingerprint = searchTerm; + searchFingerprint = searchTerm.substring(1); validQuery = true; } @@ -217,27 +210,6 @@ public class RelaySearchServlet extends HttpServlet { } } - /* We can only accept at most two search terms for nickname and - * fingerprint. */ - int items = searchFingerprintOrNickname.size(); - items += searchFingerprint.length() > 0 ? 1 : 0; - items += searchNickname.length() > 0 ? 1 : 0; - if (items > 2) { - validQuery = false; - } - - /* If we have two candidates for fingerprint or nickname and we can - * recognize what one of them is, then we can conclude what the other - * one must be. */ - else if (items == 2 && searchFingerprintOrNickname.size() == 1) { - if (searchFingerprint.length() == 0) { - searchFingerprint = searchFingerprintOrNickname.first(); - } else { - searchNickname = searchFingerprintOrNickname.first(); - } - searchFingerprintOrNickname.clear(); - } - /* We only accept at most one month or three days, but not both, or * people could accidentally keep the database busy. */ if (searchDays.size() > 3 || searchMonths.size() > 1 || @@ -262,10 +234,6 @@ public class RelaySearchServlet extends HttpServlet { recognizedSearchTerms.add("fingerprint " + searchFingerprint + ""); } - for (String searchTerm : searchFingerprintOrNickname) { - recognizedSearchTerms.add("nickname or fingerprint " + searchTerm - + ""); - } if (searchIPAddress.length() > 0) { recognizedSearchTerms.add("IP address " + searchIPAddress + ""); @@ -329,12 +297,6 @@ public class RelaySearchServlet extends HttpServlet { + "address LIKE '" + searchIPAddress + "%' "); addAnd = true; } - for (String search : searchFingerprintOrNickname) { - conditionBuilder.append((addAnd ? "AND " : "") - + "(LOWER(nickname) LIKE '" + search.toLowerCase() - + "%' OR fingerprint LIKE '" + search.toLowerCase() + "%') "); - addAnd = true; - } StringBuilder queryBuilder = new StringBuilder(); queryBuilder.append("SELECT validafter, fingerprint, descriptor, " + "rawdesc FROM statusentry WHERE validafter IN (SELECT " diff --git a/web/WEB-INF/relay-search.jsp b/web/WEB-INF/relay-search.jsp index 0741aca..260b7dc 100644 --- a/web/WEB-INF/relay-search.jsp +++ b/web/WEB-INF/relay-search.jsp @@ -34,10 +34,10 @@ <c:if test="${not empty invalidQuery}"> Sorry, I didn't understand your query. Please provide a nickname (e.g., "gabelmoo"), at least the first 8 hex characters - of a fingerprint (e.g., "F2044413"), or at least the first two - octets of an IPv4 address in dotted-decimal notation (e.g., - "80.190"). You can also provide at most three months or days in - ISO 8601 format (e.g., "2010-09" or "2010-09-17"). + of a fingerprint prefixed by $ (e.g., "$F2044413"), or at least + the first two octets of an IPv4 address in dotted-decimal notation + (e.g., "80.190"). You can also provide at most three months or + days in ISO 8601 format (e.g., "2010-09" or "2010-09-17"). </c:if> <c:if test="${not empty searchNotice}"> ${searchNotice} @@ -79,3 +79,4 @@ </div> </body> </html> +

1 0

[translation/tsum] Update translations for tsum
by translation＠torproject.org 07 Nov '11

07 Nov '11

commit cd9f6118932194ffd87cf9d08ae214c2af6e128f Author: Translation commit bot <translation(a)torproject.org> Date: Mon Nov 7 12:45:04 2011 +0000 Update translations for tsum --- pt/tsum.po | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/pt/tsum.po b/pt/tsum.po index 3394fb7..50931aa 100644 --- a/pt/tsum.po +++ b/pt/tsum.po @@ -10,7 +10,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2011-11-05 17:16+0000\n" -"PO-Revision-Date: 2011-11-07 12:14+0000\n" +"PO-Revision-Date: 2011-11-07 12:18+0000\n" "Last-Translator: nert_t <e.nertt(a)gmail.com>\n" "Language-Team: LANGUAGE <LL(a)li.org>\n" "MIME-Version: 1.0\n" @@ -22,7 +22,7 @@ msgstr "" #. type: Plain text #: en/tsum.text:2 msgid "# The Short User Manual\n" -msgstr "" +msgstr "# Manual Rápido de Utilização\n" #. type: Plain text #: en/tsum.text:7

1 0

[translation/tsum] Update translations for tsum
by translation＠torproject.org 07 Nov '11

07 Nov '11

commit 41197ed7fcacd58719af74563af805be397db678 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Nov 7 12:15:04 2011 +0000 Update translations for tsum --- pt/tsum.po | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/pt/tsum.po b/pt/tsum.po index 097c996..3394fb7 100644 --- a/pt/tsum.po +++ b/pt/tsum.po @@ -4,13 +4,14 @@ # # Translators: # <caiocajazeiras12(a)gmail.com>, 2011. +# <e.nertt(a)gmail.com>, 2011. msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2011-11-05 17:16+0000\n" -"PO-Revision-Date: 2011-11-05 21:28+0000\n" -"Last-Translator: runasand <runa.sandvik(a)gmail.com>\n" +"PO-Revision-Date: 2011-11-07 12:14+0000\n" +"Last-Translator: nert_t <e.nertt(a)gmail.com>\n" "Language-Team: LANGUAGE <LL(a)li.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -373,6 +374,11 @@ msgid "" "[https://check.torproject.org/](https://check.torproject.org/). You can now " "browse the Internet through Tor." msgstr "" +"Quando inicia o Pacote de Navegação Tor, vai primeiro ver o Vidalia iniciar " +"e ligar à rede Tor. Depois disso, vai ver o browser confirmar que está a " +"utilizar o Tor. Isto é visto em " +"[https://check.torproject.org/](https://check.torproject.org/). Pode agora " +"navegar através de Tor." #. type: Plain text #: en/tsum.text:163 @@ -381,6 +387,8 @@ msgid "" "*Please note that it is important that you use the browser that comes\n" "with the bundle, and not your own browser.*\n" msgstr "" +"*Note que é importante que utilize o browser que acompanha o pacote, e não o" +" seu browser habitual.*\n" #. type: Plain text #: en/tsum.text:169 @@ -482,6 +490,7 @@ msgstr "" #: en/tsum.text:235 msgid "Open the Vidalia control panel, click on *Settings*." msgstr "" +"Abra o painel de controlo do Vidala, clique em *Settings*/*Configurações*." #. type: Bullet: '2. ' #: en/tsum.text:235

1 0

[tor-cloud/master] Fetch from https, not http
by runa＠torproject.org 07 Nov '11

07 Nov '11

commit bd35adb7d840055caeb423221ca633253b427498 Author: Runa A. Sandvik <runa.sandvik(a)gmail.com> Date: Mon Nov 7 10:52:52 2011 +0000 Fetch from https, not http --- build.sh | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/build.sh b/build.sh index 249fba3..d09580a 100755 --- a/build.sh +++ b/build.sh @@ -24,8 +24,8 @@ # modified to run as a Tor bridge relay, private relay or middle realy on Amazon EC2 # Define your Amazon credentials for ec2-api-tools to function -export EC2_PRIVATE_KEY=/home/architect/pk.cert -export EC2_CERT=/home/architect/cert.pem +export EC2_PRIVATE_KEY=/path/to/pk.cert +export EC2_CERT=/path/to/cert.pem relaytype=$1; @@ -51,7 +51,7 @@ fi echo ${region} echo ${arch} -qurl=http://uec-images.ubuntu.com/query/lucid/server/released.current.txt +qurl=https://uec-images.ubuntu.com/query/lucid/server/released.current.txt curl --silent ${qurl} | grep ebs ami=$(curl --silent "${qurl}" | awk '-F\t' '$5 == "ebs" && $6 == arch && $7 == region { print $8 }' arch=$arch region=$region ) aki=$(curl --silent "${qurl}" | awk '-F\t' '$5 == "ebs" && $6 == arch && $7 == region { print $9 }' arch=$arch region=$region ) @@ -84,7 +84,7 @@ ec2-attach-volume --instance ${iid} --region ${region} --device /dev/sdh ${vol} echo "After attaching the volume, sleep for 20 seconds..." sleep 20 -ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i ${sshkey} ubuntu@${host} -q -t "sudo chown ubuntu:ubuntu /mnt && cd /mnt && wget http://uec-images.ubuntu.com/releases/10.04/release/ubuntu-10.04-server-uec… -O ubuntu-10.04-server-uec-i386.tar.gz && tar -Sxvzf /mnt/ubuntu-10.04-server-uec-i386.tar.gz && sudo mkdir src target && sudo mount -o loop,rw /mnt/lucid-server-uec-i386.img /mnt/src && sudo mkfs.ext4 -F -L uec-rootfs /dev/sdh && sudo mount /dev/sdh /mnt/target" +ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i ${sshkey} ubuntu@${host} -q -t "sudo chown ubuntu:ubuntu /mnt && cd /mnt && wget https://uec-images.ubuntu.com/releases/10.04/release/ubuntu-10.04-server-cl… -O ubuntu-10.04-server-cloudimg-i386.tar.gz && tar -Sxvzf /mnt/ubuntu-10.04-server-cloudimg-i386.tar.gz && sudo mkdir src target && sudo mount -o loop,rw /mnt/lucid-server-uec-i386.img /mnt/src && sudo mkfs.ext4 -F -L uec-rootfs /dev/sdh && sudo mount /dev/sdh /mnt/target" # TODO: fix GPG verification, exit on failed verification #ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i ~/keys/tor-cloud.pem ubuntu@${host} -q -t "gpg --verify /mnt/SHA256SUMS.gpg /mnt/SHA256SUMS &> /mnt/verify.txt && cat /mnt/verify.txt | grep Good | awk {'print $2'})"

1 0