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

[translation/bridgedb] Update translations for bridgedb
by translation＠torproject.org 17 Jul '18

17 Jul '18

commit 4350a942ee8833f1f60e869e162d911140b34661 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Jul 17 16:45:05 2018 +0000 Update translations for bridgedb --- pt_BR/LC_MESSAGES/bridgedb.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pt_BR/LC_MESSAGES/bridgedb.po b/pt_BR/LC_MESSAGES/bridgedb.po index 0c9738bc1..b703af0bc 100644 --- a/pt_BR/LC_MESSAGES/bridgedb.po +++ b/pt_BR/LC_MESSAGES/bridgedb.po @@ -23,8 +23,8 @@ msgstr "" "Project-Id-Version: The Tor Project\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: 2018-07-15 20:03+0000\n" -"Last-Translator: jhqpinto <jhqpinto(a)vivaldi.net>\n" +"PO-Revision-Date: 2018-07-17 16:42+0000\n" +"Last-Translator: Gustavo Vasconcelos <vasconcelos(a)gmail.com>\n" "Language-Team: Portuguese (Brazil) (http://www.transifex.com/otf/torproject/language/pt_BR/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n"

1 0

[torspec/master] dir-spec: specify failure modes for the bandwdith file headers vote line
by nickm＠torproject.org 17 Jul '18

17 Jul '18

commit 2cce07d59a5391f8b6d9e1c8805ce1889b15f127 Author: teor <teor2345(a)gmail.com> Date: Mon Jul 16 13:24:35 2018 +1000 dir-spec: specify failure modes for the bandwdith file headers vote line Closes 26799. --- dir-spec.txt | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/dir-spec.txt b/dir-spec.txt index f2447c2..6408d87 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2091,7 +2091,7 @@ [At most once for votes; does not occur in consensuses.] - KeyValues ::= KeyValue | KeyValues SP KeyValue + KeyValues ::= "" | KeyValue | KeyValues SP KeyValue KeyValue ::= Keyword '=' Value Value ::= ArgumentCharValue+ ArgumentCharValue ::= any printing ASCII character except NL and SP. @@ -2099,6 +2099,12 @@ The headers from the bandwidth file used to generate this vote. The bandwidth file headers are described in bandwidth-file-spec.txt. + If an authority is not configured with a V3BandwidthsFile, this line + SHOULD NOT appear in its vote. + + If an authority is configured with a V3BandwidthsFile, but parsing + fails, this line SHOULD appear in its vote, but without any headers. + Current Keywords: "timestamp" -- the Unix Epoch time in seconds of the most recent generator result.

1 0

[torspec/master] Merge remote-tracking branch 'teor/bug26799'
by nickm＠torproject.org 17 Jul '18

17 Jul '18

commit 1fb4cb58e98af3d4ac153efe6d0ddc43665d9a74 Merge: c0b2dc9 2cce07d Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jul 17 08:49:30 2018 -0400 Merge remote-tracking branch 'teor/bug26799' dir-spec.txt | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)

1 0

[translation/exoneratorproperties_completed] Update translations for exoneratorproperties_completed
by translation＠torproject.org 17 Jul '18

17 Jul '18

commit c498161c4f6654cd009a7773d8c82450171c7fb5 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Jul 17 12:48:43 2018 +0000 Update translations for exoneratorproperties_completed --- nl/exonerator.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nl/exonerator.properties b/nl/exonerator.properties index 6d499a7cf..6c3937872 100644 --- a/nl/exonerator.properties +++ b/nl/exonerator.properties @@ -1,4 +1,4 @@ -form.explanation=Vul een datum en IP-adres in om te zien of deze gebruikt is als tussenpoort: +form.explanation=Vul een datum en IP-adres in om te zien of deze gebruikt is als Tor relay: form.ip.label=IP-adres form.timestamp.label=Datum form.search.label=Zoeken

1 0

[translation/exoneratorproperties] Update translations for exoneratorproperties
by translation＠torproject.org 17 Jul '18

17 Jul '18

commit a5ea30754cb08fda5a742180b23bd661caa68556 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Jul 17 12:48:37 2018 +0000 Update translations for exoneratorproperties --- nl/exonerator.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nl/exonerator.properties b/nl/exonerator.properties index 6d499a7cf..6c3937872 100644 --- a/nl/exonerator.properties +++ b/nl/exonerator.properties @@ -1,4 +1,4 @@ -form.explanation=Vul een datum en IP-adres in om te zien of deze gebruikt is als tussenpoort: +form.explanation=Vul een datum en IP-adres in om te zien of deze gebruikt is als Tor relay: form.ip.label=IP-adres form.timestamp.label=Datum form.search.label=Zoeken

1 0

[torspec/master] Authorities expose bandwidth file used in votes
by nickm＠torproject.org 17 Jul '18

17 Jul '18

commit 365d371ab5942051257f86214b215601583c22f0 Author: juga0 <juga(a)riseup.net> Date: Mon Jul 9 10:53:57 2018 +0000 Authorities expose bandwidth file used in votes In a similar ways as authorities expose the votes for the next consensus. This way it can be archived by CollectTor --- dir-spec.txt | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/dir-spec.txt b/dir-spec.txt index bcb04a5..388ad04 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2599,6 +2599,28 @@ IPv4 addresses (two /8 networks) were blocked. The list is encoded as described in section 3.8.2. +3.4.3 Serving bandwidth list files + + If an authority has used a bandwidth list file to generate a vote + document it SHOULD make it available at + + http://<hostname>/tor/status-vote/next/bandwidth.z + + at the start of each voting period. + If an authority makes this file available, it MUST be the bandwidth file + used to create the vote document available at + + http://<hostname>/tor/status-vote/next/authority.z + + Once the voting period starts, the bandwidth list file SHOULD be available + at + + http://<hostname>/tor/status-vote/next/bandwidth.z + + The bandwidth list file is described in bandwidth-file-spec.txt. + + First-appeared in Tor 0.3.5. + 3.5. Downloading missing certificates from other directory authorities XXX when to download certificates. @@ -4013,4 +4035,3 @@ E. Limited ed diff format just a period (".") ends the block (and is not part of the lines to add). Note that it is impossible to insert a line with just a single dot. -

1 0

[torspec/master] Have Directory Authorities expose bandwidth files
by nickm＠torproject.org 17 Jul '18

17 Jul '18

commit 58d3cb9cc2e7d3e2600365eed34f7b2ad7c8813f Author: juga0 <juga(a)riseup.net> Date: Tue Jul 10 12:05:50 2018 +0000 Have Directory Authorities expose bandwidth files Proposal sent to tor-dev maling list by Tom Ritter. (https://lists.torproject.org/pipermail/tor-dev/2017-December/012677.html) --- proposals/xxx-expose-bwauth_votes.txt | 78 +++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) diff --git a/proposals/xxx-expose-bwauth_votes.txt b/proposals/xxx-expose-bwauth_votes.txt new file mode 100644 index 0000000..af6532a --- /dev/null +++ b/proposals/xxx-expose-bwauth_votes.txt @@ -0,0 +1,78 @@ +Filename: xxx-expose-bwauth_votes.txt +Title: Have Directory Authorities expose raw bwauth vote documents +Author: Tom Ritter +Created: 11-December-2017 +Status: Open +Ticket: https://trac.torproject.org/projects/tor/ticket/21377 + +1. Introduction + +Bandwidth Authorities (bwauths) perform scanning of the Tor Network +and calculate observed speeds for each relay. They produce a 'bwauth +vote file' that is given to a Directory Authority. The Directory +Authority uses the speed value from this file in its vote file +denoting its view of the speed of the relay. + +After collecting all of the votes from other Authorities, a consensus +is calculated, and the consensus's view of a relay's speed is +determined by choosing the low-median value of all the authorities' +values for each relay. + +Only a single metric from the bwauth vote file is exposed by a +Directory Authority's vote, however the original file contains +considerably more diagnostic information about how the bwauth arrives +at that measurement for that relay. + +2. Motivation + +The bwauth vote file contains more information than is exposed in the +overall vote file. This information is useful to debug anomalies in +relays' utilization and suspected bugs in the (decrepit) bwauth code. + +Currently, all bwauths expose the raw vote file through various (non- +standard) means, and that file is downloaded (hourly) by a single person +(as long as his home internet connection and home server is working) +and archived (with a small amount of robustness.) + +It would be preferable to have this exposed in a standard manner. +Doing so would no longer require bwauths to run HTTP servers to expose +the file, no longer require them to take additional manual steps to +provide it, and would enable public consumption by any interested +parties. We hope that Collector will begin archiving the files. + +3. Specification + +An authority SHOULD publish the bwauth vote used to calculate its +current vote. It SHOULD make the bwauth vote file available at all +times, and provide the file that it has most recently used for its +vote (even if the vote is not currently published.) It SHOULD make +the file available at + http://<hostname>/tor/status-vote/now/bwauth-legacy.z + +It MUST NOT attempt to send its bwauth vote file in a HTTP POST to +other authorities and it SHOULD NOT make bwauth vote files from other +authorities available. + +Clients interested in consuming the document should download it when +votes are created. (For the existing Tor network, this is at HH:50, +or 50 minutes after each hour.) + +4. Security Implications + +The raw bwauth vote file does not [really: is not believed to] expose +any sensitive information. All authorities currently make this +document public already, an example is at + https://bwauth.ritter.vg/bwauth/bwscan.V3BandwidthsFile + +5. Compatibility + +Exposing the document presents no compatibility concerns. + +The compatibility concern is with applications that want to consume +the document. The bwauth vote file has no specification, and has been +extended in ad-hoc ways. Applications that merely wish to archive the +document (e.g. Collector) won't have a problems. Applications that +want to parse it may encounter errors if a new (unexpected) field is +added, if a new format is specified and fields are removed, or +assumptions are made about the text encoding or formatting of the +document. \ No newline at end of file

1 0

[torspec/master] bandwidth: edit bandwidth URL dir-spec and proposal
by nickm＠torproject.org 17 Jul '18

17 Jul '18

commit d29d9ada0bf86167edc647285534b8d75890a593 Author: teor <teor2345(a)gmail.com> Date: Mon Jul 16 10:16:18 2018 +1000 bandwidth: edit bandwidth URL dir-spec and proposal * dir-spec: don't post bandwidth files to other authorities * dir-spec: add URL for current bandwidth file * dir-spec: clean up the consensus and vote "current" publication schedule Closes ticket #21377. --- dir-spec.txt | 26 +++++++------- ...th_votes.txt => xxx-expose-bandwidth-files.txt} | 41 ++++++++++++++-------- 2 files changed, 39 insertions(+), 28 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 388ad04..df74ca8 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2607,19 +2607,19 @@ http://<hostname>/tor/status-vote/next/bandwidth.z at the start of each voting period. + + It MUST NOT attempt to send its bandwidth list file in a HTTP POST to + other authorities and it SHOULD NOT make bandwidth list files from other + authorities available. + If an authority makes this file available, it MUST be the bandwidth file used to create the vote document available at http://<hostname>/tor/status-vote/next/authority.z - Once the voting period starts, the bandwidth list file SHOULD be available - at + The bandwidth list format is described in bandwidth-file-spec.txt. - http://<hostname>/tor/status-vote/next/bandwidth.z - - The bandwidth list file is described in bandwidth-file-spec.txt. - - First-appeared in Tor 0.3.5. + The standard URLs for bandwidth list files first-appeared in Tor 0.3.5. 3.5. Downloading missing certificates from other directory authorities @@ -3343,16 +3343,14 @@ 3.11. Publishing the signed consensus - Once there are enough signatures, or once the voting period starts, - these documents are available at + The voting period ends at the valid-after time. If the consensus has + been signed by a majority of authorities, these documents are made + available at http://<hostname>/tor/status-vote/current/consensus.z and http://<hostname>/tor/status-vote/current/consensus-signatures.z [XXX current/consensus-signatures is not currently implemented, as it is not used in the voting protocol.] - [XXX It's actually false that the first document is available as soon - as there are enough signatures. It's only available as soon as the - voting period starts. -KL] [XXX possible future features include support for downloading old consensuses.] @@ -3361,13 +3359,15 @@ http://<hostname>/tor/status-vote/current/authority.z http://<hostname>/tor/status-vote/current/<fp>.z http://<hostname>/tor/status-vote/current/d/<d>.z - once the consensus is complete. + http://<hostname>/tor/status-vote/current/bandwidth.z + once the voting period ends, regardless of the number of signatures. The authorities serve another consensus of each flavor "F" from the locations /tor/status-vote/(current|next)/consensus-F.z. and /tor/status-vote/(current|next)/consensus-F/<FP1>+....z. + The standard URLs for bandwidth list files first-appeared in Tor 0.3.5. 4. Directory cache operation diff --git a/proposals/xxx-expose-bwauth_votes.txt b/proposals/xxx-expose-bandwidth-files.txt similarity index 64% rename from proposals/xxx-expose-bwauth_votes.txt rename to proposals/xxx-expose-bandwidth-files.txt index 93a6f1a..12abe0e 100644 --- a/proposals/xxx-expose-bwauth_votes.txt +++ b/proposals/xxx-expose-bandwidth-files.txt @@ -1,5 +1,5 @@ -Filename: xxx-expose-bwauth_votes.txt -Title: Have Directory Authorities expose raw bandwidth list file documents +Filename: xxx-expose-bandwidth-files.txt +Title: Have Directory Authorities expose raw bandwidth list files Author: Tom Ritter Created: 11-December-2017 Status: Open @@ -8,10 +8,10 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/21377 1. Introduction Bandwidth Authorities (bwauths) perform scanning of the Tor Network -and calculate observed speeds for each relay. They produce a bandwidth +and calculate observed bandwidths for each relay. They produce a bandwidth list file that is given to a Directory Authority. The Directory -Authority uses the speed value from this file in its vote file -denoting its view of the speed of the relay. +Authority uses the bw (bandwidth) value from this file in its vote file +denoting its view of the bandwidth of the relay. After collecting all of the votes from other Authorities, a consensus is calculated, and the consensus's view of a relay's speed is @@ -23,16 +23,21 @@ Directory Authority's vote, however the original file contains considerably more diagnostic information about how the bwauth arrives at that measurement for that relay. +For more details, see the bandwidth list file specification in +bandwidth-file-spec.txt. + 2. Motivation The bandwidth list file contains more information than is exposed in the -overall vote file. This information is useful to debug anomalies in -relays' utilization and suspected bugs in the (decrepit) bwauth code. +overall vote file. This information is useful to debug: + * anomalies in relays' utilization, + * suspected bugs in the (decrepit) bwauth code, and + * the transition to a replacement bwauth implementation. Currently, all bwauths expose the bandwidth list file through various (non- standard) means, and that file is downloaded (hourly) by a single person (as long as his home internet connection and home server is working) -and archived (with a small amount of robustness.) +and archived (with a small amount of robustness.) It would be preferable to have this exposed in a standard manner. Doing so would no longer require bwauths to run HTTP servers to expose @@ -43,19 +48,25 @@ parties. We hope that Collector will begin archiving the files. 3. Specification An authority SHOULD publish the bandwidth list file used to calculate its -current vote. It SHOULD make the bandwidth list file available at all -times, and provide the file that it has most recently used for its -vote (even if the vote is not currently published.) It SHOULD make -the file available at +next vote. It SHOULD make the bandwidth list file available whenever the +corresponding vote is available, at the corresponding URL. (See +dir-spec for the exact details.) + +It SHOULD make the file available at http://<hostname>/tor/status-vote/next/bandwidth.z + http://<hostname>/tor/status-vote/current/bandwidth.z It MUST NOT attempt to send its bandwidth list file in a HTTP POST to other authorities and it SHOULD NOT make bandwidth list files from other authorities available. -Clients interested in consuming the document should download it when -votes are created. (For the existing Tor network, this is at HH:50, -or 50 minutes after each hour.) +Clients interested in consuming these documents should download them from +each authority's: + * next URL when votes are created. (In the public Tor network, this is + after HH:50 during normal operation, and after HH:20 during a + consensus failure.) + * current URL after the valid-after time in the consensus. + (After HH:00, and HH:30 during consensus failure.) 4. Security Implications

1 0

[torspec/master] Merge remote-tracking branch 'teor/ticket21377-squashed'
by nickm＠torproject.org 17 Jul '18

17 Jul '18

commit b3abfdffeef063a3672679fb092a4d9ff08a605b Merge: d31c33c d29d9ad Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jul 17 08:45:48 2018 -0400 Merge remote-tracking branch 'teor/ticket21377-squashed' dir-spec.txt | 35 ++++++++++--- proposals/xxx-expose-bandwidth-files.txt | 85 ++++++++++++++++++++++++++++++++ 2 files changed, 113 insertions(+), 7 deletions(-)

1 0

[torspec/master] Edit bandwidth file URL proposal
by nickm＠torproject.org 17 Jul '18

17 Jul '18

commit 96145da5e224e85161a83bc26c0b57685da2d9eb Author: juga0 <juga(a)riseup.net> Date: Tue Jul 10 12:11:42 2018 +0000 Edit bandwidth file URL proposal * Correct URL with the one in the dir-spec * Replace bwauth vote/raw file by bandwidth list file * Update compatibility, the format has a spec --- proposals/xxx-expose-bwauth_votes.txt | 36 ++++++++++++++++------------------- 1 file changed, 16 insertions(+), 20 deletions(-) diff --git a/proposals/xxx-expose-bwauth_votes.txt b/proposals/xxx-expose-bwauth_votes.txt index af6532a..93a6f1a 100644 --- a/proposals/xxx-expose-bwauth_votes.txt +++ b/proposals/xxx-expose-bwauth_votes.txt @@ -1,5 +1,5 @@ Filename: xxx-expose-bwauth_votes.txt -Title: Have Directory Authorities expose raw bwauth vote documents +Title: Have Directory Authorities expose raw bandwidth list file documents Author: Tom Ritter Created: 11-December-2017 Status: Open @@ -8,8 +8,8 @@ Ticket: https://trac.torproject.org/projects/tor/ticket/21377 1. Introduction Bandwidth Authorities (bwauths) perform scanning of the Tor Network -and calculate observed speeds for each relay. They produce a 'bwauth -vote file' that is given to a Directory Authority. The Directory +and calculate observed speeds for each relay. They produce a bandwidth +list file that is given to a Directory Authority. The Directory Authority uses the speed value from this file in its vote file denoting its view of the speed of the relay. @@ -18,18 +18,18 @@ is calculated, and the consensus's view of a relay's speed is determined by choosing the low-median value of all the authorities' values for each relay. -Only a single metric from the bwauth vote file is exposed by a +Only a single metric from the bandwidth list file is exposed by a Directory Authority's vote, however the original file contains considerably more diagnostic information about how the bwauth arrives at that measurement for that relay. 2. Motivation -The bwauth vote file contains more information than is exposed in the +The bandwidth list file contains more information than is exposed in the overall vote file. This information is useful to debug anomalies in relays' utilization and suspected bugs in the (decrepit) bwauth code. -Currently, all bwauths expose the raw vote file through various (non- +Currently, all bwauths expose the bandwidth list file through various (non- standard) means, and that file is downloaded (hourly) by a single person (as long as his home internet connection and home server is working) and archived (with a small amount of robustness.) @@ -42,15 +42,15 @@ parties. We hope that Collector will begin archiving the files. 3. Specification -An authority SHOULD publish the bwauth vote used to calculate its -current vote. It SHOULD make the bwauth vote file available at all +An authority SHOULD publish the bandwidth list file used to calculate its +current vote. It SHOULD make the bandwidth list file available at all times, and provide the file that it has most recently used for its vote (even if the vote is not currently published.) It SHOULD make the file available at - http://<hostname>/tor/status-vote/now/bwauth-legacy.z + http://<hostname>/tor/status-vote/next/bandwidth.z -It MUST NOT attempt to send its bwauth vote file in a HTTP POST to -other authorities and it SHOULD NOT make bwauth vote files from other +It MUST NOT attempt to send its bandwidth list file in a HTTP POST to +other authorities and it SHOULD NOT make bandwidth list files from other authorities available. Clients interested in consuming the document should download it when @@ -59,7 +59,7 @@ or 50 minutes after each hour.) 4. Security Implications -The raw bwauth vote file does not [really: is not believed to] expose +The raw bandwidth list file does not [really: is not believed to] expose any sensitive information. All authorities currently make this document public already, an example is at https://bwauth.ritter.vg/bwauth/bwscan.V3BandwidthsFile @@ -68,11 +68,7 @@ document public already, an example is at Exposing the document presents no compatibility concerns. -The compatibility concern is with applications that want to consume -the document. The bwauth vote file has no specification, and has been -extended in ad-hoc ways. Applications that merely wish to archive the -document (e.g. Collector) won't have a problems. Applications that -want to parse it may encounter errors if a new (unexpected) field is -added, if a new format is specified and fields are removed, or -assumptions are made about the text encoding or formatting of the -document. \ No newline at end of file +Applications that parse the document should follow the bandwidth list file +specification in bandwidth-file-spec.txt. +If a new bandwidth list format version is added, the applications MAY need +to upgrade to that version. \ No newline at end of file

1 0