August 2017 - tor-commits - lists.torproject.org

[tor-browser-build/master] Add a torbrowser_build option and use it in the build output directory
by boklm＠torproject.org 07 Aug '17

07 Aug '17

commit 9d18c95bc22bb3df18c4839d21715ce7df9c1ee8 Author: Nicolas Vigier <boklm(a)torproject.org> Date: Mon Aug 7 19:47:53 2017 +0200 Add a torbrowser_build option and use it in the build output directory --- projects/release/config | 10 +++++----- rbm.conf | 1 + 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/projects/release/config b/projects/release/config index 3351959..43a36e8 100644 --- a/projects/release/config +++ b/projects/release/config @@ -4,7 +4,7 @@ output_dir: 'release/unsigned' var: today: '[% USE date; date.format(format = "%Y-%m-%d") %]' - publish_dir: '[% c("version") %]' + publish_dir: '[% c("version") %]-[% c("var/torbrowser_build") %]' targets: torbrowser-all: @@ -39,13 +39,13 @@ targets: nightly: output_dir: 'nightly' - version: '[% c("var/today") %]' + publish_dir: '[% c("var/today") %]' var: build_target: nightly alpha_nightly: output_dir: 'alpha_nightly' - version: '[% c("var/today") %]' + publish_dir: '[% c("var/today") %]' var: build_target: alpha @@ -56,13 +56,13 @@ targets: testbuild: output_dir: 'testbuild' - version: '.' + publish_dir: '' var: build_target: torbrowser-testbuild hardened_nightly: output_dir: 'hardened_nightly' - version: '[% c("var/today") %]' + publish_dir: '[% c("var/today") %]' var: build_target: hardened diff --git a/rbm.conf b/rbm.conf index 46d487c..13d19a5 100644 --- a/rbm.conf +++ b/rbm.conf @@ -14,6 +14,7 @@ buildconf: var: torbrowser_version: '7.5a4' + torbrowser_build: 'build1' project_name: tor-browser multi_lingual: 0 build_mar: 1

1 0

[torspec/master] Add my proposal-280 draft (privcount in tor)
by nickm＠torproject.org 07 Aug '17

07 Aug '17

commit ce09d266b817e4466f823f821a9ff8fbe0740b96 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Aug 7 13:39:27 2017 -0400 Add my proposal-280 draft (privcount in tor) --- proposals/000-index.txt | 2 + proposals/280-privcount-in-tor.txt | 332 +++++++++++++++++++++++++++++++++++++ 2 files changed, 334 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 5dc4395..54d5bc4 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -200,6 +200,7 @@ Proposals by number: 277 Detect multiple relay instances running with same ID [OPEN] 278 Directory Compression Scheme Negotiation [FINISHED] 279 A Name System API for Tor Onion Services [DRAFT] +280 Privacy-Preseving Statistics with Privcount in Tor [DRAFT] Proposals by status: @@ -223,6 +224,7 @@ Proposals by status: 270 RebelAlliance: A Post-Quantum Secure Hybrid Handshake Based on NewHope 273 Exit relay pinning for web services [for n/a] 279 A Name System API for Tor Onion Services + 280 Privacy-Preseving Statistics with Privcount in Tor NEEDS-REVISION: 190 Bridge Client Authorization Based on a Shared Secret NEEDS-RESEARCH: diff --git a/proposals/280-privcount-in-tor.txt b/proposals/280-privcount-in-tor.txt new file mode 100644 index 0000000..c51eb33 --- /dev/null +++ b/proposals/280-privcount-in-tor.txt @@ -0,0 +1,332 @@ +Filename: 280-privcount-in-tor.txt +Title: Privacy-Preseving Statistics with Privcount in Tor +Author: Nick Mathewson, Tim Wilson-Brown +Created: 02-Aug-2017 +Status: Draft + +0. Acknowledgments + + Tariq Elahi, George Danezis, and Ian Goldberg designed and implemented + the PrivEx blinding scheme. Rob Jansen and Aaron Johnson extended + PrivEx's differential privacy guarantees to multiple counters in + PrivCount: + + https://github.com/privcount/privcount/blob/master/README.markdown#research… + + Rob Jansen and Tim Wilson-Brown wrote the majority of the experimental + PrivCount code, based on the PrivEx secret-sharing variant. This + implementation includes contributions from the PrivEx authors, and + others: + + https://github.com/privcount/privcount/blob/master/CONTRIBUTORS.markdown + +1. Introduction and scope + + PrivCount is a privacy-preserving way to collect aggregate statistics + about the Tor network without exposing the statistics from any single + Tor relay. + + This document describes the behavior of the in-Tor portion of the + PrivCount system. It DOES NOT describe the counter configurations, + or any other parts of the system. (These will be covered in separate + proposals.) + +2. PrivCount overview + + Here follows an oversimplified summary of PrivCount, with enough + information to explain the Tor side of things. The actual operation + of the non-Tor components is trickier than described below. + + All values in the scheme below are 64-bit unsigned integers; addition + and subtraction are modulo 2^64. + + In PrivCount, a Data Collector (in this case a Tor relay) shares + numeric data with N different Tally Reporters. (A Tally Reporter + performs the summing and unblinding roles of the Tally Server and Share + Keeper from experimental PrivCount.) + + All N Tally Reporters together can reconstruct the original data, but + no (N-1)-sized subset of the Tally Reporters can learn anything about + the data. + + (In reality, the Tally Reporters don't reconstruct the original data + at all! Instead, they will reconstruct a _sum_ of the original data + across all participating relays.) + + To share data, for each value X to be shared, the relay generates + random values B_1 though B_n, and shares each B_i secretly with a + single Tally Reporter. The relay then publishes Y = X + SUM(B_i) + Z, + where Z is a noise value taken at random from a gaussian distribution. + The Tally Reporters can reconstruct X+Z by securely computing SUM(B_i) + across all contributing Data Collectors. (Tally Reporters MUST NOT + share individual B_i values: that would expose the underlying relay + totals.) + + In order to prevent bogus data from corrupting the tally, the Tor + relays and the Tally Reporters perform multiple "instances" of this + algorithm, randomly sampling in each relays. The relay sends multiple + Y values for each measurement, built with different sets of B_i. + These "instances" are numbered in order from 1 to R. + + So that the system will still produce results in the event of a single + Tally Reporter failure, these instances are distributed across multiple + subsets of Tally Reporters. + + Below we describe a data format for this. + +3. The document format + + This document format builds on the line-based directory format used + for other tor documents, described in Tor's dir-spec.txt. + + Using this format, we describe two kinds of documents here: a + "counters" document that publishes all the Y values, and a "blinding" + document that describes the B_i values. But see "An optimized + alternative" below. + + The "counters" document has these elements: + + "privctr-dump-format" SP VERSION SP SigningKey + + [At start, exactly once] + + Describes the version of the dump format, and provides an ed25519 + signing key to identify the relay. The signing key is encoded in + base64 with padding stripped. VERSION is "alpha" now, but should + be "1" once this document is finalized. + + [[[TODO: Do we need a counter version as well? + + Noise is distributed across a particular set of counters, + to provide differential privacy guarantees for those counters. + Reducing noise requires a break in the collection. + Adding counters is ok if the noise on each counter + monotonically increases. (Removing counters always reduces + noise.) + + We also need to work out how to handle instances with mixed + Tor versions, where some Data Collectors report different + counters to other Data Collectors. (The blinding works if we + substitute zeroes for missing counters on Tally Reporters. + But we also need to add noise in this case.) + + -teor + ]]] + + "starting-at" SP IsoTime + + [Exactly once] + + The start of the time period when the statistics here were + collected. + + "ending-at" SP IsoTime + + [Exactly once] + + The end of the time period when the statistics here were + collected. + + "num-instances" SP Number + + [Exactly once] + + The number of "instances" that the relay used (see above.) + + "tally-reporter" SP Identifier SP Key SP InstanceNumbers + + [At least twice] + + The curve25519 public key of each Tally Reporter that the relay + believes in. (If the list does not match the list of + participating tally reporters, they won't be able to find the + relay's values correctly.) The identifiers are non-space, + non-nul character sequences. The Key values are encoded in + base64 with padding stripped; they must be unique within each + counters document. The InstanceNumbers are comma-separated lists + of decimal integers from 0 to (num-instances - 1), in ascending + order. + + Keyword ":" SP Int SP Int SP Int ... + + [Any number of times] + + The Y values for a single measurement. There are num-instances + such Y values for each measurement. They are 64-bit unsigned + integers, expressed in decimal. + + The "Keyword" denotes which measurement is being shared. Keyword + MAY be any sequence of characters other than colon, nul, space, + and newline, though implementators SHOULD avoid getting too + creative here. Keywords MUST be unique within a single document. + Tally Reporters MUST handle unrecognized keywords. Keywords MAY + appear in any order. + + It is safe to send the blinded totals for each instance to every + Tally Reporter. To unblind the totals, a Tally Reporter needs: + * a blinding document from each relay in the instance, and + * the per-counter blinding sums from the other Tally Reporters + in their instance. + + [[[TODO: But is it safer to create a per-instance counters + document? -- teor]]] + + The semantics of individual measurements are not specified here. + + "signature" SP Signature + + [At end, exactly once] + + The Ed25519 signature of all the fields in the document, from the + first byte, up to but not including the "signature" keyword here. + The signature is encoded in base64 with padding stripped. + + + The "blinding" document has these elements: + + "privctr-secret-offsets" SP VERSION SP SigningKey + + [At start, exactly once.] + + The VERSION and SigningKey parameters are the same as for + "privctr-dump-format". + + "instances" SP Numbers + + [Exactly once] + + The instances that this Tally Reporter handles. + They are given as comma-separated decimal integers, as in the + "tally-reporter" entry in the counters document. They MUST + match the instances listed in the counters document. + + [[[TODO: this is redundant. Specify the constraint instead? --teor]]] + + "num-counters" SP Number + + [Exactly once] + + The number of counters that the relay used in its counters + document. This MUST be equal to the number of keywords in the + counters document. + + [[[TODO: this is redundant. Specify the constraint instead? --teor]]] + + "tally-reporter-pubkey" SP Key + + [Exactly once] + + The curve25519 public key of the tally reporter who is intended + to receive an decrypt this document. The key is base64-encoded + with padding stripped. + + "count-document-digest" SP "sha3" Digest NL + "-----BEGIN ENCRYPTED DATA-----" NL + Data + "-----END ENCRYPTED DATA-----" NL + + [Exactly once] + + The SHA3-256 digest of the count document corresponding to this + blinding document. The digest is base64-encoded with padding + stripped. The data encodes the blinding values (See "The + Blinding Values") below, and is encrypted to the tally reporter's + public key using the hybrid encryption algorithm described below. + + "signature" SP Signature + + [At end, exactly once] + + The Ed25519 signature of all the fields in the document, from the + first byte, up to but not including the "signature" keyword here. + The signature is encoded in base64 with padding stripped. + + +4. The Blinding Values + + The "Data" field of the blinding documents above, when decrypted, + yields a sequence of 64-bit binary values, encoded in network + (big-endian) order. There are C * R such values, where C is the number + of keywords in the count document, and R is the number of instances + that the Tally Reporter participates in. The client generates all of + these values uniformly at random. + + For each keyword in the count document, in the order specified by the + count document, the decrypted data holds R*8 bytes for the specified + instance of that keyword's blinded counter. + + For example: if the count document lists the keywords "b", "x", "g", + and "a" (in that order), and lists instances "0", and "2", then the + decrypted data will hold the blinding values in this order: + b, instance 0 + b, instance 2 + x, instance 0 + x, instance 2 + g, instance 0 + g, instance 2 + a, instance 0 + a, instance 2 + + +4. Implementation Notes + + A relay should, when starting a new round, generate all the blinding + values and noise values in advance. The relay should then use these + values to compute Y_0 = SUM(B_i) + Z for each instance of each + counter. Having done this, the relay MUST encrypt the blinding values + to the public key of each tally reporter, and wipe them from memory. + + +5. The hybrid encryption algorithm + + We use a hybrid encryption scheme above, where items can be encrypted + to a public key. We instantiate it as follows, using curve25519 + public keys. + + To encrypt a plaintext M to a public key PK1 + 1. the sender generates a new ephemeral keypair sk2, PK2. + 2. The sender computes the shared diffie hellman secret + SEED = (sk2 * PK1). + + 3. The sender derives 64 bytes of key material as + SHAKE256(TEXT | SEED)[...64] + where "TEXT" is "Expand curve25519 for privcount encryption". + + The first 32 bytes of this is an aes key K1; + the second 32 bytes are a mac key K2. + + 4. The sender computes a ciphertext C as AES256_CTR(K1, M) + + 5. The sender computes a MAC as + SHA3_256([00 00 00 00 00 00 00 20] | K2 | C) + + 6. The hybrid-encrypted text is PK2 | MAC | C. + + +6. An optimized alternative + + As an alternative, the sequences of blinding values is NOT transmitted + to the tally reporters. Instead the client generates a single + ephemeral keypair sk_c, PK_c, and places the public key in its counts + document. It does this each time a new round begins. + + For each tally reporter with public key PK_i, the client then does + the handshake sk_c * PK_i to compute SEED_i. + + The client then generates the blinding values for that tally reporter + as SHAKE256(SEED_i)[...R*C*8]. + + After initializing the counters to Y_0, the client can discard the + blinding values and sk_c. + + Later, the tally reporters can reconstruct the blinding values as + SHAKE256(sk_i * PK_c)[...] + + This alternative allows the client to transmit only a single public + key, when previously it would need to transmit a complete set of + blinding factors for each tally reporter. Further, the alternative + does away with the need for blinding documents altogether. It is, + however, more sensitive to any defects in SHAKE256 than the design + above. Like the rest of this design, it would need rethinking if we + want to expand this scheme to work with anonymous data collectors, + such as Tor clients.

1 0

[webwml/master] Modify contact page w support
by hiro＠torproject.org 07 Aug '17

07 Aug '17

commit a085cc077d31e8f59e60467ba5628d1d590d6f8c Author: hiromipaw <hiro(a)torproject.org> Date: Mon Aug 7 18:48:52 2017 +0200 Modify contact page w support --- about/en/contact.wml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/about/en/contact.wml b/about/en/contact.wml index 055e0016..50addf28 100644 --- a/about/en/contact.wml +++ b/about/en/contact.wml @@ -42,8 +42,7 @@ <p>If you have questions about using Tor:</p> <ol> - <li>Read through the <a href="<page docs/faq>">FAQ</a> and the - <a href="<page docs/documentation>">documentation</a>.</li> + <li>Check our <a href="https://trac.torproject.org/projects/tor/wiki/org/teams/CommunityTeam/Suppo…">support wiki</a> for answers to some of the most frequently asked questions about Tor.</li> <li>See if your question is asked or answered on our <a href="https://tor.stackexchange.com/">StackExchange page</a>. If it isn't, please consider asking it there! Then everybody else can

1 0

[webwml/master] Merge branch 'master' of ssh://git-rw.torproject.org/project/web/webwml
by hiro＠torproject.org 07 Aug '17

07 Aug '17

commit 1cfaef279fc3242e1396e7924ac7388d7ca302f7 Merge: a085cc07 1a9bc4f0 Author: hiromipaw <hiro(a)torproject.org> Date: Mon Aug 7 18:49:00 2017 +0200 Merge branch 'master' of ssh://git-rw.torproject.org/project/web/webwml Makefile | 4 +- about/en/corepeople.wml | 89 ++++---- include/versions.wmi | 4 +- keys/juris.txt | 321 +++++++++++++++++++++++++++++ projects/torbrowser/RecommendedTBBVersions | 1 - 5 files changed, 374 insertions(+), 45 deletions(-)

1 0

[atlas/master] Remove titles from the family members entries
by irl＠torproject.org 07 Aug '17

07 Aug '17

commit b97485fcfb1b6c208eb8aa6e8191319da564fa3a Author: cypherpunks <cypherpunks(a)torproject.org> Date: Thu May 25 12:09:59 2017 +0000 Remove titles from the family members entries The titles do not provide extra information other than the type of family member which is already in the header. Closes #22379. --- templates/details/router.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/templates/details/router.html b/templates/details/router.html index 76b8ff6..4ee112e 100644 --- a/templates/details/router.html +++ b/templates/details/router.html @@ -120,13 +120,13 @@ <dt><span class="tip" title="Relays that are part of this relay's family and consider this relay to be part of their family.">Effective Family Members</span></dt> <dd> <pre><% if (relay.get('effective_family') !== null) { %><% _.each(relay.get('effective_family'), function(member) { %><% var valid = member.match(RegExp("^\$[A-F0-9]{40}$")); %> -<% if (valid) { %><a href="#details/<%= member.replace('$', '') %>" title="Effective family member"><% } %><%= member %><% if (valid) { %></a><% }}); %> +<% if (valid) { %><a href="#details/<%= member.replace('$', '') %>"><% } %><%= member %><% if (valid) { %></a><% }}); %> <% } else { %>none<% } %></pre> </dd> <dt><span class="tip" title="Relays that are part of this relay's family but don't consider this relay to be part of their family.">Alleged Family Members</span></dt> <dd> <pre><% if (relay.get('alleged_family') !== null) { %><% _.each(relay.get('alleged_family'), function(member) { %><% var valid = member.match(RegExp("^\$[A-F0-9]{40}$")); %> -<% if (valid) { %><a href="#details/<%= member.replace('$', '') %>" title="Alleged family member" class="alleged"><% } %><%= member %><% if (valid) { %></a><% }}); %> +<% if (valid) { %><a href="#details/<%= member.replace('$', '') %>" class="alleged"><% } %><%= member %><% if (valid) { %></a><% }}); %> <% } else { %>none<% } %></pre> </dd>

1 0

[atlas/master] Remove the static width from the status column
by irl＠torproject.org 07 Aug '17

07 Aug '17

commit 81fe8ba192535114c2ff6207c4eb55dd203ccd88 Author: cypherpunks <cypherpunks(a)torproject.org> Date: Sat May 27 13:28:41 2017 +0000 Remove the static width from the status column --- templates/search/do.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/templates/search/do.html b/templates/search/do.html index 41c3175..006860f 100644 --- a/templates/search/do.html +++ b/templates/search/do.html @@ -55,7 +55,7 @@ <table class="table table-bordered table-striped" id="torstatus_results"> <thead> <tr> - <th style="width:16px;"> </th> + <th></th> <th>Nickname</th> <th>Bandwidth</th> <th>Uptime</th>

1 0

[atlas/master] Replace the relay status icons with CSS
by irl＠torproject.org 07 Aug '17

07 Aug '17

commit 66c2ccdc616a4d29d49cb298bf1e5c07cb75f81f Author: cypherpunks <cypherpunks(a)torproject.org> Date: Mon May 8 11:42:07 2017 +0000 Replace the relay status icons with CSS Closes #22416. --- css/style.css | 19 +++++++++++++++++++ img/properties/offline_16x16.png | Bin 229 -> 0 bytes img/properties/online_16x16.png | Bin 230 -> 0 bytes templates/details/bridge.html | 4 ++-- templates/details/router.html | 4 ++-- templates/search/do.html | 4 ++-- 6 files changed, 25 insertions(+), 6 deletions(-) diff --git a/css/style.css b/css/style.css index e4b3a81..c1c91c6 100644 --- a/css/style.css +++ b/css/style.css @@ -44,6 +44,25 @@ input { width:150px; } +.circle { + display: inline-block; + vertical-align: middle; + background: #999999; + width: 10px; + height: 10px; + -moz-border-radius: 50%; + -webkit-border-radius: 50%; + border-radius: 50%; +} + +.circle-online { + background: #25d918; +} + +.circle-offline { + background: #ff1515; +} + @media screen and (max-width: 980px) { .nav-collapse ul { padding-top:20px; diff --git a/img/properties/offline_16x16.png b/img/properties/offline_16x16.png deleted file mode 100644 index 9af422b..0000000 Binary files a/img/properties/offline_16x16.png and /dev/null differ diff --git a/img/properties/online_16x16.png b/img/properties/online_16x16.png deleted file mode 100644 index 37a4e5b..0000000 Binary files a/img/properties/online_16x16.png and /dev/null differ diff --git a/templates/details/bridge.html b/templates/details/bridge.html index c4b93c0..8c9b1b4 100644 --- a/templates/details/bridge.html +++ b/templates/details/bridge.html @@ -1,9 +1,9 @@ <h1> Details for: <%= relay.get('nickname') %> <% if (relay.get('running') === false) { %> - <img class="tip" src="img/properties/offline_16x16.png" alt="Offline" title="This bridge is offline."/> + <span class="tip circle circle-offline" title="This bridge is offline."></span> <% } else { %> - <img class="tip" src="img/properties/online_16x16.png" alt="Running" title="This bridge is running."/> + <span class="tip circle circle-online" title="This bridge is running."></span> <% } %> </h1> diff --git a/templates/details/router.html b/templates/details/router.html index 4ee112e..f0f3105 100644 --- a/templates/details/router.html +++ b/templates/details/router.html @@ -1,9 +1,9 @@ <h1> Details for: <%= relay.get('nickname') %> <% if (relay.get('running') === false) { %> - <img class="tip" src="img/properties/offline_16x16.png" alt="Offline" title="This relay is offline."/> + <span class="tip circle circle-offline" title="This relay is offline."></span> <% } else { %> - <img class="tip" src="img/properties/online_16x16.png" alt="Running" title="This relay is running."/> + <span class="tip circle circle-online" title="This relay is running."></span> <% } %> </h1> diff --git a/templates/search/do.html b/templates/search/do.html index 56d8396..41c3175 100644 --- a/templates/search/do.html +++ b/templates/search/do.html @@ -79,9 +79,9 @@ <% } %> <td> <% if (relay.get('running') === false) { %> - <img class="tip inline flags" src="img/properties/offline_16x16.png" alt="Currently offline" title="This relay is currently offline."/> + <span class="tip circle circle-offline" title="This relay is offline."></span> <% } else { %> - <img class="tip inline flags" src="img/properties/online_16x16.png" alt="Currently running" title="This relay is currently running."/> + <span class="tip circle circle-online" title="This relay is running."></span> <% } %> </td> <td>

1 0

[atlas/master] Hash the fingerprints from summary documents
by irl＠torproject.org 07 Aug '17

07 Aug '17

commit 40426f09f37ff84f93f20f156ab638ce27ff977a Author: cypherpunks <cypherpunks(a)torproject.org> Date: Sat May 20 11:46:36 2017 +0000 Hash the fingerprints from summary documents The summary documents are used for searches and form the basis for subsequent details document requests. The details documents requests use the lookup parameter which supports hashed and double hashed fingerprints to prevent users leaking bridge fingerprints. If a relay and a bridge share the same fingerprint FP (for example when a bridge becomes a relay without changing its fingerprint) the summary document for fingerprint FP contains both the relay fingerprint RP (where RP == FP) and the hashed bridge fingerprint BP (where BP == H(FP)). The details document request for RP returns only the relay because RP == FP and the details document request for BP returns the relay and the bridge because BP == H(FP) == H(RP). Relays take preference over bridges when both are returned and results in Atlas displaying the relay details twice on the search page. Hashing the fingerprints in the summary document results in details document requests for BP and H(BP) where BP returns the relay and bridge as before but where H(BP) returns only the bridge. Closes #21615. --- js/collections/results.js | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/js/collections/results.js b/js/collections/results.js index c341321..54cd36a 100644 --- a/js/collections/results.js +++ b/js/collections/results.js @@ -3,8 +3,9 @@ define([ 'jquery', 'underscore', 'backbone', - 'models/relay' -], function($, _, Backbone, relayModel){ + 'models/relay', + 'jssha' +], function($, _, Backbone, relayModel, jsSHA){ var resultsCollection = Backbone.Collection.extend({ model: relayModel, baseurl: 'https://onionoo.torproject.org/summary?search=', @@ -24,12 +25,12 @@ define([ } _.each(response.relays, function(relay, resultsC) { crelay = new relayModel; - crelay.fingerprint = relay.f; + crelay.fingerprint = new jsSHA(relay.f, "HEX").getHash("SHA-1", "HEX").toUpperCase(); relays.push(crelay); }); _.each(response.bridges, function(relay, resultsC) { crelay = new relayModel; - crelay.fingerprint = relay.h; + crelay.fingerprint = new jsSHA(relay.h, "HEX").getHash("SHA-1", "HEX").toUpperCase(); relays.push(crelay); }); if (relays.length == 0) {

1 0

[tor-browser-build/master] Refresh keyring/firefox.gpg
by boklm＠torproject.org 07 Aug '17

07 Aug '17

commit 5ef1e3f8014542af7409ad973601b73a15acf119 Author: Nicolas Vigier <boklm(a)torproject.org> Date: Mon Aug 7 17:17:08 2017 +0200 Refresh keyring/firefox.gpg --- keyring/firefox.gpg | Bin 11220 -> 13463 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/keyring/firefox.gpg b/keyring/firefox.gpg index fa6d1b5..9c71261 100644 Binary files a/keyring/firefox.gpg and b/keyring/firefox.gpg differ

1 0

[translation/https_everywhere_completed] Update translations for https_everywhere_completed
by translation＠torproject.org 07 Aug '17

07 Aug '17

commit 9f4d70d2ce497c8fa7615a9cff853b1aed28966f Author: Translation commit bot <translation(a)torproject.org> Date: Mon Aug 7 15:15:39 2017 +0000 Update translations for https_everywhere_completed --- pl/https-everywhere.dtd | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/pl/https-everywhere.dtd b/pl/https-everywhere.dtd index 930ec75c0..f548a6d29 100644 --- a/pl/https-everywhere.dtd +++ b/pl/https-everywhere.dtd @@ -24,9 +24,22 @@ <!ENTITY https-everywhere.menu.showCounter "Pokaż Licznik"> <!ENTITY https-everywhere.menu.viewAllRules "Wyświetl wszystkie reguły"> +<!ENTITY https-everywhere.options.importSettings "Importuj ustawienia"> +<!ENTITY https-everywhere.options.import "Importuj"> +<!ENTITY https-everywhere.options.imported "Twoje ustawienia zostały zaimportowane."> + <!ENTITY https-everywhere.prefs.title "Ustawienia HTTPS Everywhere"> <!ENTITY https-everywhere.prefs.enable_all "Włącz wszystko"> <!ENTITY https-everywhere.prefs.disable_all "Wyłącz wszystko"> +<!ENTITY https-everywhere.prefs.export_settings "Eksportuj ustawienia"> +<!ENTITY https-everywhere.prefs.settings_warning "Ostrzeżenie:"> +<!ENTITY https-everywhere.prefs.settings_warning_delete "Niektóre ustawienia HTTPS Everywhere mają zostać usunięte!"> +<!ENTITY https-everywhere.prefs.settings_warning_explain "To rozszerzenie zostanie w znacznym stopniu uaktualnione w najbliższej przyszłości. Jeśli nie wyeksportujesz ustawień, możesz stracić jedno lub więcej z następujących:"> +<!ENTITY https-everywhere.prefs.settings_global "Globalne preferencje"> +<!ENTITY https-everywhere.prefs.settings_toggle "Ustawienie włącz/wyłącz na stronę"> +<!ENTITY https-everywhere.prefs.settings_custom "Niestandardowe reguły strony"> +<!ENTITY https-everywhere.prefs.settings_click_ok "Proszę kliknąć 'OK'"> +<!ENTITY https-everywhere.prefs.settings_warning_closing "poniżej, aby upewnić się, że ustawienia zapisano. Gdy HTTPS Everywhere zostanie zaktualizowany, później będziesz musiał zaimportować te ustawienia w sekcji opcji rozszerzenia."> <!ENTITY https-everywhere.prefs.reset_defaults "Przywróć ustawienia fabryczne"> <!ENTITY https-everywhere.prefs.search "Szukaj"> <!ENTITY https-everywhere.prefs.site "Strona">

1 0