tor-commits April 2016

tor-commits@lists.torproject.org

20 participants
1645 discussions

[tor/master] Adopt the LCOV convention for marking lines as unreachable by tests.
by nickm＠torproject.org 19 Apr '16

19 Apr '16

commit 4043f2c95f4a47e69edc4d451673b7ffda066768 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 12 21:12:10 2016 -0400 Adopt the LCOV convention for marking lines as unreachable by tests. Document this convention. Add a script to post-process .gcov files in order to stop nagging us about excluded lines. Teach cov-diff to handle these post-processed files. Closes ticket 16792 --- changes/lcov_excl | 7 +++++++ doc/HACKING/WritingTests.md | 13 +++++++++++++ scripts/test/cov-diff | 4 ++-- scripts/test/cov-exclude | 28 ++++++++++++++++++++++++++++ 4 files changed, 50 insertions(+), 2 deletions(-) diff --git a/changes/lcov_excl b/changes/lcov_excl new file mode 100644 index 0000000..474181c --- /dev/null +++ b/changes/lcov_excl @@ -0,0 +1,7 @@ + o Minor features (testing): + - Use the lcov convention for marking lines as unreachable, so that + we don't count them when we're generating test coverage data. + Update our coverage tools to understand this convention. + Closes ticket #16792. + + diff --git a/doc/HACKING/WritingTests.md b/doc/HACKING/WritingTests.md index bd2ee0e..7bcadc6 100644 --- a/doc/HACKING/WritingTests.md +++ b/doc/HACKING/WritingTests.md @@ -109,6 +109,19 @@ To count new or modified uncovered lines in D2, you can run: ./scripts/test/cov-diff ${D1} ${D2}" | grep '^+ *\#' | wc -l +### Marking lines as unreachable by tests + +You can mark a specific line as unreachable by using the special +string LCOV_EXCL_LINE. You can mark a range of lines as unreachable +with LCOV_EXCL_START... LCOV_EXCL_STOP. Note that older versions of +lcov don't understand these lines. + +You can post-process .gcov files to make these lines 'unreached' by +running ./scripts/test/cov-exclude on them. + +Note: you should never do this unless the line is meant to 100% +unreachable by actual code. + What kinds of test should I write? ---------------------------------- diff --git a/scripts/test/cov-diff b/scripts/test/cov-diff index 48dbec9..7da7f0b 100755 --- a/scripts/test/cov-diff +++ b/scripts/test/cov-diff @@ -9,8 +9,8 @@ DIRB="$2" for A in $DIRA/*; do B=$DIRB/`basename $A` - perl -pe 's/^\s*\d+:/ 1:/; s/^([^:]+:)[\d\s]+:/$1/; s/^ *-:(Runs|Programs):.*//;' "$A" > "$A.tmp" - perl -pe 's/^\s*\d+:/ 1:/; s/^([^:]+:)[\d\s]+:/$1/; s/^ *-:(Runs|Programs):.*//;' "$B" > "$B.tmp" + perl -pe 's/^\s*\!*\d+:/ 1:/; s/^([^:]+:)[\d\s]+:/$1/; s/^ *-:(Runs|Programs):.*//;' "$A" > "$A.tmp" + perl -pe 's/^\s*\!*\d+:/ 1:/; s/^([^:]+:)[\d\s]+:/$1/; s/^ *-:(Runs|Programs):.*//;' "$B" > "$B.tmp" diff -u "$A.tmp" "$B.tmp" rm "$A.tmp" "$B.tmp" done diff --git a/scripts/test/cov-exclude b/scripts/test/cov-exclude new file mode 100755 index 0000000..5117f11 --- /dev/null +++ b/scripts/test/cov-exclude @@ -0,0 +1,28 @@ +#!/usr/bin/perl -p -i + +use warnings; +use strict; +our $excluding; + +# This script is meant to post-process a .gcov file for an input source +# that was annotated with LCOV_EXCL_START, LCOV_EXCL_STOP, and LCOV_EXCL_LINE +# entries. It doesn't understand the LCOV_EXCL_BR* variations. +# +# It replaces unreached reached lines with x:, and reached excluded lines +# with !!!num:. + +BEGIN { our $excluding = 0; } + +if (m/LCOV_EXCL_START/) { + $excluding = 1; +} +if ($excluding and m/LCOV_EXCL_STOP/) { + $excluding = 0; +} + +my $exclude_this = (m/LCOV_EXCL_LINE/); + +if ($excluding or $exclude_this) { + s{^\s*\#\#+:}{ x:}; + s{^ (\s*)(\d+):}{$1!!!$2:}; +}

1 0

[tor/master] Merge remote-tracking branch 'public/lcov_excl'
by nickm＠torproject.org 19 Apr '16

19 Apr '16

commit 94e3555187d44d8a4c87421654a2288a3525fdc4 Merge: 12e26a6 0630f19 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 19 14:05:51 2016 -0400 Merge remote-tracking branch 'public/lcov_excl' changes/lcov_excl | 7 +++++++ doc/HACKING/WritingTests.md | 13 +++++++++++++ scripts/test/cov-diff | 4 ++-- scripts/test/cov-exclude | 28 ++++++++++++++++++++++++++++ src/common/crypto.c | 16 ++++++++++------ src/common/crypto_s2k.c | 6 ++++-- 6 files changed, 64 insertions(+), 10 deletions(-)

1 0

[tor-browser/tor-browser-45.0.2esr-6.x-1] fixup! TB3: Tor Browser's official .mozconfigs.
by gk＠torproject.org 19 Apr '16

19 Apr '16

commit 833436c0e36649d47df22567b23343c76985243a Author: Georg Koppen <gk(a)torproject.org> Date: Thu Mar 31 12:43:33 2016 +0000 fixup! TB3: Tor Browser's official .mozconfigs. Bug 18331: Update .mozconfig for new cross-compiler --- .mozconfig-mac | 39 ++++++++++++++++++++++++++++----------- 1 file changed, 28 insertions(+), 11 deletions(-) diff --git a/.mozconfig-mac b/.mozconfig-mac index dc77c3b..c5ca087 100644 --- a/.mozconfig-mac +++ b/.mozconfig-mac @@ -1,28 +1,45 @@ -CROSS_COMPILE=1 +# ld needs libLTO.so from llvm +mk_add_options "export LD_LIBRARY_PATH=$topsrcdir/clang/lib" -SYSROOTDIR="$HOME/build/MacOSX10.7.sdk" -CROSS_PRIVATE_FRAMEWORKS="$SYSROOTDIR/System/Library/PrivateFrameworks" -ROOTDIR="$HOME/build/x-tools/x86_64-apple-darwin10/bin" -TOOLCHAIN_PREFIX="$ROOTDIR/x86_64-apple-darwin10-" +CROSS_CCTOOLS_PATH=$topsrcdir/cctools +CROSS_SYSROOT=$topsrcdir/MacOSX10.7.sdk +CROSS_PRIVATE_FRAMEWORKS=$CROSS_SYSROOT/System/Library/PrivateFrameworks +FLAGS="-target x86_64-apple-darwin10 -mlinker-version=136 -B $CROSS_CCTOOLS_PATH/bin -isysroot $CROSS_SYSROOT" -FLAGS="-arch x86_64 -isysroot $SYSROOTDIR" -CC="$ROOTDIR/x86_64-apple-darwin10-clang $FLAGS" -CXX="$ROOTDIR/x86_64-apple-darwin10-clang++ $FLAGS" +export CC="$topsrcdir/clang/bin/clang $FLAGS" +export CXX="$topsrcdir/clang/bin/clang++ $FLAGS" +export CPP="$topsrcdir/clang/bin/clang $FLAGS -E" +export LLVMCONFIG=$topsrcdir/clang/bin/llvm-config +export LDFLAGS="-Wl,-syslibroot,$CROSS_SYSROOT -Wl,-dead_strip" +export TOOLCHAIN_PREFIX=$CROSS_CCTOOLS_PATH/bin/x86_64-apple-darwin10- +#TODO: bug 1184202 - would be nice if these could be detected with TOOLCHAIN_PREFIX automatically +export AR=${TOOLCHAIN_PREFIX}ar +export RANLIB=${TOOLCHAIN_PREFIX}ranlib +export STRIP=${TOOLCHAIN_PREFIX}strip +export OTOOL=${TOOLCHAIN_PREFIX}otool +export DSYMUTIL=$topsrcdir/clang/bin/llvm-dsymutil + +export HOST_CC="$topsrcdir/clang/bin/clang" +export HOST_CXX="$topsrcdir/clang/bin/clang++" +export HOST_CPP="$topsrcdir/clang/bin/clang -E" +export HOST_CFLAGS="-g" +export HOST_CXXFLAGS="-g" +export HOST_LDFLAGS="-g" + +ac_add_options --target=x86_64-apple-darwin +ac_add_options --with-macos-private-frameworks=$CROSS_PRIVATE_FRAMEWORKS mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-macos mk_add_options MOZ_APP_DISPLAYNAME="Tor Browser" mk_add_options MOZILLA_OFFICIAL=1 mk_add_options BUILD_OFFICIAL=1 -ac_add_options --target=x86_64-apple-darwin10 ac_add_options --enable-application=browser ac_add_options --enable-strip ac_add_options --enable-official-branding ac_add_options --enable-optimize ac_add_options --disable-debug -ac_add_options --with-macos-private-frameworks="$CROSS_PRIVATE_FRAMEWORKS" - ac_add_options --enable-tor-browser-data-outside-app-dir ac_add_options --enable-tor-browser-update ac_add_options --enable-update-packaging

1 0

[tor-browser/tor-browser-45.0.2esr-6.x-1] fixup! TB4: Tor Browser's Firefox preference overrides.
by gk＠torproject.org 19 Apr '16

19 Apr '16

commit be482a800166d85c2f52d39f34c1d620abc07c87 Author: Georg Koppen <gk(a)torproject.org> Date: Tue Apr 19 13:31:25 2016 +0000 fixup! TB4: Tor Browser's Firefox preference overrides. We disable Selfsupport and Unified Telemetry (and set another datareporting URL to "data:text/plain,"). This is bug 18738. --- browser/app/profile/000-tor-browser.js | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/browser/app/profile/000-tor-browser.js b/browser/app/profile/000-tor-browser.js index 6ec7c26..3b859bc 100644 --- a/browser/app/profile/000-tor-browser.js +++ b/browser/app/profile/000-tor-browser.js @@ -72,6 +72,10 @@ pref("datareporting.policy.dataSubmissionEnabled", false); // Don't fetch a localized remote page that Tor Browser interacts with, see // #16727. And, yes, it is "reportUrl" and not "reportURL". pref("datareporting.healthreport.about.reportUrl", "data:text/plain,"); +// Make sure Selfsupport and Unified Telemetry are really disabled, see: #18738. +pref("datareporting.healthreport.about.reportUrlUnified", "data:text/plain,"); +pref("browser.selfsupport.enabled", false); +pref("toolkit.telemetry.unified", false); pref("security.mixed_content.block_active_content", false); // Disable until https://bugzilla.mozilla.org/show_bug.cgi?id=878890 is patched pref("browser.syncPromoViewsLeftMap", "{\"addons\":0, \"passwords\":0, \"bookmarks\":0}"); // Don't promote sync pref("services.sync.engine.prefs", false); // Never sync prefs, addons, or tabs with other browsers

1 0

[translation/tails-onioncircuits] Update translations for tails-onioncircuits
by translation＠torproject.org 19 Apr '16

19 Apr '16

commit 91ffa26690869ed2a239a876fd77c064dfe65fb7 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 19 13:16:48 2016 +0000 Update translations for tails-onioncircuits --- fa/onioncircuits.pot | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/fa/onioncircuits.pot b/fa/onioncircuits.pot index c086830..639b51e 100644 --- a/fa/onioncircuits.pot +++ b/fa/onioncircuits.pot @@ -3,13 +3,14 @@ # This file is distributed under the same license as the PACKAGE package. # # Translators: +# NoProfile, 2016 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2016-03-26 00:31+0100\n" -"PO-Revision-Date: 2016-03-30 03:31+0000\n" -"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" +"POT-Creation-Date: 2016-03-31 21:31+0200\n" +"PO-Revision-Date: 2016-04-19 12:57+0000\n" +"Last-Translator: NoProfile\n" "Language-Team: Persian (http://www.transifex.com/otf/torproject/language/fa/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -24,11 +25,11 @@ msgstr "" #: ../onioncircuits:94 msgid "Onion Circuits" -msgstr "" +msgstr "مدارهای پیاز" #: ../onioncircuits:95 msgid "Display Tor circuits and streams" -msgstr "" +msgstr "نمایش مدارهای Tor و جریان ها" #: ../onioncircuits:107 msgid "OK" @@ -44,7 +45,7 @@ msgstr "وضعیت" #: ../onioncircuits:141 msgid "Click on a path to get details" -msgstr "" +msgstr "کلیک کنید روی یک مسیر برای دریافت جزئیات" #: ../onioncircuits:215 msgid "" @@ -57,12 +58,12 @@ msgstr "" #: ../onioncircuits:314 msgid "Building..." -msgstr "" +msgstr "درحال ساختن..." #: ../onioncircuits:339 #, c-format msgid "%s: %s" -msgstr "" +msgstr "%s: %s" #: ../onioncircuits:564 msgid "Fingerprint:" @@ -70,16 +71,16 @@ msgstr "اثر انگشت:" #: ../onioncircuits:565 msgid "Published:" -msgstr "" +msgstr "منتشر شده:" #: ../onioncircuits:566 msgid "IP:" -msgstr "" +msgstr "آی پی:" #: ../onioncircuits:566 #, c-format msgid "%s (%s)" -msgstr "" +msgstr "%s (%s)" #: ../onioncircuits:567 msgid "Bandwidth:" @@ -88,4 +89,4 @@ msgstr "پهنای باند:" #: ../onioncircuits:567 #, c-format msgid "%.2f Mb/s" -msgstr "" +msgstr "%.2f مگابایت در ثانیه"

1 0

[torspec/master] prop224: Switch back to a TYPE/LEN/KEY construction for cells.
by asn＠torproject.org 19 Apr '16

19 Apr '16

commit 95a64b03cdb8f2254c11f33fc8ebb24b9d9be369 Author: George Kadianakis <desnacked(a)riseup.net> Date: Thu Apr 14 13:14:37 2016 +0300 prop224: Switch back to a TYPE/LEN/KEY construction for cells. Nick pointed out that having the length explicit is better for backwards/future compatibility. Also change some field names so that they are mostly uniform throughout the proposal. --- proposals/224-rend-spec-ng.txt | 56 ++++++++++++++++++------------------------ 1 file changed, 24 insertions(+), 32 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 1edbc08..001d2ba 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -152,19 +152,6 @@ Status: Draft themselves, but over those strings prefixed with a distinguishing value. - Through this proposal we use the following construction when sending - cryptographic keys in tor cells: - - KEYTYPE [1 byte] - KEY [depends on KEYTYPE] - - In this case the size of the KEY depends on the KEYTYPE. Here are the - currently defined key types: - - * The KEYTYPE value [01] is for Ed25519 keys (size: 32 bytes). - * The KEYTYPE value [02] is for Curve25519 keys (size: 32 bytes). - * The KEYTYPE value [03] is for truncated Curve25519 keys (size: 8 bytes). - 0.4. Protocol building blocks [BUILDING-BLOCKS] In sections below, we need to transmit the locations and identities @@ -1192,10 +1179,12 @@ Status: Draft An INTRODUCE1 cell has the following contents: - AUTH_KEYTYPE [1 byte] - AUTH_KEYID [depends on AUTH_KEYTYPE] - ENC_KEYTYPE [1 byte] - ENC_KEYID [depends on ENC_KEYTYPE] + AUTH_KEY_TYPE [1 byte] + AUTH_KEY_LEN [1 byte] + AUTH_KEY [AUTH_KEY_LEN bytes] + ENC_KEY_TYPE [1 byte] + ENC_KEY_LEN [1 byte] + ENC_KEY [ENC_KEY_LEN bytes] N_EXTENSIONS [1 byte] N_EXTENSIONS times: EXT_FIELD_TYPE [1 byte] @@ -1208,20 +1197,20 @@ Status: Draft encryption method? The latter is probably safer.] Upon receiving an INTRODUCE1 cell, the introduction point checks - whether AUTH_KEYID and ENC_KEYID match a configured introduction + whether AUTH_KEY and ENC_KEY match a configured introduction point authentication key and introduction point encryption key. If they do, the cell is relayed; if not, it is not. - (After checking AUTH_KEYID and ENC_KEYID and finding no match, the - introduction point should check to see whether a legacy hidden service is - running whose PK_ID is the first 20 bytes of AUTH_KEYID. If so, it - behaves as in rend-spec.txt.) + (After checking AUTH_KEY and ENC_KEY and finding no match, the introduction + point should check to see whether a legacy hidden service is running whose + PK_ID is the first 20 bytes of AUTH_KEY. If so, it behaves as in + rend-spec.txt.) - The AUTH_KEYTYPE is an Ed25519 public key (value [01]). + The AUTH_KEY_TYPE is an Ed25519 public key (value [01]). - The ENC_KEYTYPE is a truncated Curve25519 public key (value [03]). (This key + The ENC_KEY_TYPE is a truncated Curve25519 public key (value [03]). (This key is safe to truncate, since all the keys are generated by the hidden service - host, and the ID is only valid relative to a single AUTH_KEYID.) The + host, and the ID is only valid relative to a single AUTH_KEY.) The ENCRYPTED field is as described in 3.3 below. To relay an INTRODUCE1 cell, the introduction point sends an @@ -1296,7 +1285,8 @@ Status: Draft EXT_FIELD_LEN [1 byte] EXT_FIELD [EXT_FIELD_LEN bytes] ONION_KEY_TYPE [1 bytes] - ONION_KEY [depends on ONION_KEY_TYPE] + ONION_KEY_LEN [1 bytes] + ONION_KEY [ONION_KEY_LEN bytes] NSPEC (Number of link specifiers) [1 byte] NSPEC times: LSTYPE (Link specifier type) [1 byte] @@ -1394,10 +1384,12 @@ Status: Draft Substituting those fields into the INTRODUCE1 cell body format described in [FMT_INTRO1] above, we have - AUTH_KEYTYPE [1 byte] - AUTH_KEYID [depends on AUTH_KEYTYPE] - ENC_KEYTYPE [1 byte] - ENC_KEYID [depends on ENC_KEYTYPE] + AUTH_KEY_TYPE [1 byte] + AUTH_KEY_LEN [1 byte] + AUTH_KEY [AUTH_KEY_LEN bytes] + ENC_KEY_TYPE [1 byte] + ENC_KEY_LEN [1 byte] + ENC_KEY [ENC_KEY_LEN bytes] N_EXTENSIONS [1 bytes] N_EXTENSIONS times: EXT_FIELD_TYPE [1 byte] @@ -1416,10 +1408,10 @@ Status: Draft described in [LEGACY-INTRODUCE1].) Here, the encryption key plays the role of B in the regular ntor - handshake, and the AUTH_KEYID field plays the role of the node ID. + handshake, and the AUTH_KEY field plays the role of the node ID. The CLIENT_PK field is the public key X. The ENCRYPTED_DATA field is the message plaintext, encrypted with the symmetric key ENC_KEY. The - MAC field is a MAC of all of the cell from the AUTH_KEYID through the + MAC field is a MAC of all of the cell from the AUTH_KEY through the end of ENCRYPTED_DATA, using the MAC_KEY value as its key. To process this format, the hidden service checks PK_VALID(CLIENT_PK)

1 0

[torspec/master] prop224: Fix crypto issues pointed out by Nick.
by asn＠torproject.org 19 Apr '16

19 Apr '16

commit f2cfab04187e593b9ec28a7ebd95e674510ccbab Author: George Kadianakis <desnacked(a)riseup.net> Date: Wed Apr 13 17:20:54 2016 +0300 prop224: Fix crypto issues pointed out by Nick. - No point in using SHAKE *with* HKDF. Just use SHAKE. - Use our KDF to do key expansion for rendezvous crypto. --- proposals/224-rend-spec-ng.txt | 31 +++++++++++-------------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 833224b..1edbc08 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -125,8 +125,7 @@ Status: Draft * A cryptographic message authentication code MAC(key,msg) that produces outputs of length MAC_LEN bytes. - * A key derivation function KDF(key data, salt, personalization, - n) that outputs n bytes. + * A key derivation function KDF(message, n) that outputs n bytes. As a first pass, I suggest: @@ -141,7 +140,7 @@ Status: Draft * Instantiate MAC(key=k, message=m) with H(k || m). - * Instantiate KDF with HKDF using SHAKE-256. + * Instantiate KDF with SHAKE-256. For legacy purposes, we specify compatibility with older versions of the Tor introduction point and rendezvous point protocols. These used @@ -952,7 +951,7 @@ Status: Draft secret_input = blinded_public_key(replica-keynum) | subcredential | INT_4(revision_counter) - keys = KDF(secret_input, salt, "hsdir-encrypted-data", + keys = KDF(secret_input | salt | "hsdir-encrypted-data", S_KEY_LEN + S_IV_LEN + MAC_KEY_LEN) SECRET_KEY = first S_KEY_LEN bytes of keys @@ -1381,7 +1380,7 @@ Status: Draft and computes: secret_hs_input = EXP(B,x) | AUTH_KEYID | X | B | PROTOID info = m_hsexpand | subcredential - hs_keys = HKDF(secret_hs_input, t_hsenc, info, S_KEY_LEN+MAC_LEN) + hs_keys = KDF(secret_hs_input | t_hsenc | info, S_KEY_LEN+MAC_LEN) ENC_KEY = hs_keys[0:S_KEY_LEN] MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN] @@ -1438,7 +1437,7 @@ Status: Draft secret_hs_input = EXP(X,b) | AUTH_KEYID | X | B | PROTOID info = m_hsexpand | subcredential - hs_keys = HKDF(secret_hs_input, t_hsenc, info, S_KEY_LEN+MAC_LEN) + hs_keys = KDF(secret_hs_input | t_hsenc | info, S_KEY_LEN+MAC_LEN) HS_DEC_KEY = hs_keys[0:S_KEY_LEN] HS_MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN] @@ -1580,23 +1579,15 @@ Status: Draft 4.2.1. Key expansion The hidden service and its client need to derive crypto keys from the - NTOR_KEY_SEED part of the handshake output. To do so, they use the key - expansion construction specified in prop216: + NTOR_KEY_SEED part of the handshake output. To do so, they use the KDF + construction as follows: - K = K_1 | K_2 | K_3 | ... - - Where K_1 = MAC(NTOR_KEY_SEED, m_hsexpand | INT8(1)) - and K_(i+1) = MAC(NTOR_KEY_SEED, K_i | m_hsexpand | INT8(i)) - and INT8(i) is a octet with the value "i". - - - The key material is then used to generate KH, Df, Db, Kf, and Kb as in the - KDF-TOR key derivation approach documented in tor-spec.txt: + K = KDF(NTOR_KEY_SEED | m_hsexpand, HASH_LEN * 3 + S_KEY_LEN * 2) The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward - digest Df; the next HASH_LEN 41-60 form the backward digest Db; the next - KEY_LEN 61-76 form Kf, and the final KEY_LEN form Kb. Excess bytes from K - are discarded. + digest Df; the next HASH_LEN bytes form the backward digest Db; the next + S_KEY_LEN bytes form Kf, and the final S_KEY_LEN bytes form Kb. Excess + bytes from K are discarded. Subsequently, the rendezvous point passes relay cells, unchanged, from each of the two circuits to the other. When Alice's OP sends RELAY cells along

1 0

[translation/torbutton-torbuttonproperties] Update translations for torbutton-torbuttonproperties
by translation＠torproject.org 19 Apr '16

19 Apr '16

commit ec81f320331a05a21159fd0c27db431c0435027a Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 19 11:15:55 2016 +0000 Update translations for torbutton-torbuttonproperties --- pt/torbutton.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pt/torbutton.properties b/pt/torbutton.properties index e16a5ee..b65f4a4 100644 --- a/pt/torbutton.properties +++ b/pt/torbutton.properties @@ -76,4 +76,4 @@ profileProblemTitle=%S - Problema de Perfil profileReadOnly=Não pode executar %S a partir de um sistema de ficheiros só-de-leitura. Por favor, copie %S para outra localização antes de tentar utilizá-lo. profileReadOnlyMac=Não pode executar %S a partir de um ficheiro do sistema só-de-leitura. Por favor, copie %S para o seu Ambiente de Trabalho antes de tentar utilizá-lo. profileAccessDenied=%S não tem permissão para aceder ao perfil. Por favor, ajuste as suas permissões de ficheiro do sistema e tente de novo. -profileMigrationFailed=Migration of your existing %S profile failed.\nNew settings will be used. +profileMigrationFailed=Migração do seu perfil %S existente falhou. \nNovas configurações serão utilizadas.

1 0

[translation/https_everywhere] Update translations for https_everywhere
by translation＠torproject.org 19 Apr '16

19 Apr '16

commit b780f021d2f59cfd161d314288f0be2e01d4a3a7 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 19 11:15:16 2016 +0000 Update translations for https_everywhere --- pt/https-everywhere.dtd | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/pt/https-everywhere.dtd b/pt/https-everywhere.dtd index 370469e..727912c 100644 --- a/pt/https-everywhere.dtd +++ b/pt/https-everywhere.dtd @@ -3,18 +3,18 @@ <!ENTITY https-everywhere.about.ext_description "Encripte a Web! Utilize automaticamente a segurança HTTPS em vários sites."> <!ENTITY https-everywhere.about.version "Versão"> <!ENTITY https-everywhere.about.created_by "Criado por"> -<!ENTITY https-everywhere.about.and ", and"> +<!ENTITY https-everywhere.about.and ", e"> <!ENTITY https-everywhere.about.librarians "Bibliotecas do conjunto de regras"> <!ENTITY https-everywhere.about.thanks "Obrigado a"> -<!ENTITY https-everywhere.about.many_contributors "Many many contributors, including"> -<!ENTITY https-everywhere.about.noscript "Also, portions of HTTPS Everywhere are based on code from NoScript, by Giorgio Maone and others. We are grateful for their excellent work!"> +<!ENTITY https-everywhere.about.many_contributors "Muitos, muitos contribuidores, incluindo"> +<!ENTITY https-everywhere.about.noscript "Também, partes de HTTPS por toda parte são baseadas no código vindo do NoScript, por Giorgio Maone e outros. Nós somos gratos pelo excelente trabalho deles;"> <!ENTITY https-everywhere.about.contribute "Se gosta do HTTPS Everywhere, poderá considerar"> <!ENTITY https-everywhere.about.donate_tor "Doar ao Tor"> <!ENTITY https-everywhere.about.tor_lang_code "pt-PT"> <!ENTITY https-everywhere.about.or "ou"> <!ENTITY https-everywhere.about.donate_eff "Doar à EFF"> -<!ENTITY https-everywhere.menu.donate_eff_imperative "Donate to EFF"> +<!ENTITY https-everywhere.menu.donate_eff_imperative "Doe ao EFF;"> <!ENTITY https-everywhere.menu.about "Sobre o HTTPS Everywhere"> <!ENTITY https-everywhere.menu.observatory "Preferências do Observatório de SSL"> <!ENTITY https-everywhere.menu.globalEnable "Ativar HTTPS Everywhere"> @@ -38,17 +38,17 @@ <!ENTITY https-everywhere.prefs.reset_default "Reiniciar Predefinição"> <!ENTITY https-everywhere.prefs.view_xml_source "Ver Fonte XML"> -<!ENTITY https-everywhere.chrome.stable_rules "Stable rules"> -<!ENTITY https-everywhere.chrome.stable_rules_description "Force encrypted connections to these websites:"> -<!ENTITY https-everywhere.chrome.experimental_rules "Experimental rules"> -<!ENTITY https-everywhere.chrome.experimental_rules_description "May cause warnings or breakage. Disabled by default."> -<!ENTITY https-everywhere.chrome.add_rule "Add a rule for this site"> -<!ENTITY https-everywhere.chrome.add_new_rule "Add a new rule for this site"> -<!ENTITY https-everywhere.chrome.always_https_for_host "Always use https for this host"> +<!ENTITY https-everywhere.chrome.stable_rules "Regras estáveis"> +<!ENTITY https-everywhere.chrome.stable_rules_description "Forçar conexões encriptadas a estes websites;"> +<!ENTITY https-everywhere.chrome.experimental_rules "Regras experimentais"> +<!ENTITY https-everywhere.chrome.experimental_rules_description "Pode causar alertas ou danos. Desabilitado por padrão."> +<!ENTITY https-everywhere.chrome.add_rule "Adicionar uma regra para este site"> +<!ENTITY https-everywhere.chrome.add_new_rule "Adicionar uma nova regra para este site"> +<!ENTITY https-everywhere.chrome.always_https_for_host "Sempre usar https para este host"> <!ENTITY https-everywhere.chrome.host "Host:"> -<!ENTITY https-everywhere.chrome.show_advanced "Show advanced"> +<!ENTITY https-everywhere.chrome.show_advanced "Avançado"> <!ENTITY https-everywhere.chrome.hide_advanced "Hide advanced"> -<!ENTITY https-everywhere.chrome.rule_name "Rule name"> +<!ENTITY https-everywhere.chrome.rule_name "Nome da regra"> <!ENTITY https-everywhere.chrome.regex "Matching regex"> <!ENTITY https-everywhere.chrome.redirect_to "Redirect to"> <!ENTITY https-everywhere.chrome.status_cancel_button "Cancelar">

1 0

[tor-browser/tor-browser-45.0.2esr-6.x-1] fixup! TB4: Tor Browser's Firefox preference overrides.
by gk＠torproject.org 19 Apr '16

19 Apr '16

commit 60916de81de12775e7d172b0cb46b9d71b3f6736 Author: Georg Koppen <gk(a)torproject.org> Date: Mon Apr 18 13:59:00 2016 +0000 fixup! TB4: Tor Browser's Firefox preference overrides. Enforce SHA1 deprecation (bug 18042) --- browser/app/profile/000-tor-browser.js | 3 +++ 1 file changed, 3 insertions(+) diff --git a/browser/app/profile/000-tor-browser.js b/browser/app/profile/000-tor-browser.js index 7d05149..6ec7c26 100644 --- a/browser/app/profile/000-tor-browser.js +++ b/browser/app/profile/000-tor-browser.js @@ -268,6 +268,9 @@ pref("security.tls.unrestricted_rc4_fallback", false); // Enforce certificate pinning, see: https://bugs.torproject.org/16206 pref("security.cert_pinning.enforcement_level", 2); +// Enforce SHA1 deprecation, see: bug 18042. +pref("security.pki.sha1_enforcement_level", 2); + // Workaround for https://bugs.torproject.org/13579. Progress on // `about:downloads` is only shown if the following preference is set to `true` // in case the download panel got removed from the toolbar.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits April 2016