- tor-commits - lists.torproject.org

[translation/bridgedb] Update translations for bridgedb
by translation＠torproject.org 15 Jan '16

15 Jan '16

commit 9040dbd6c2cf067d5d47c529ae481cb575e15e30 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Jan 15 05:45:03 2016 +0000 Update translations for bridgedb --- mr/LC_MESSAGES/bridgedb.po | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/mr/LC_MESSAGES/bridgedb.po b/mr/LC_MESSAGES/bridgedb.po index 77b8bca..13a8011 100644 --- a/mr/LC_MESSAGES/bridgedb.po +++ b/mr/LC_MESSAGES/bridgedb.po @@ -3,13 +3,13 @@ # This file is distributed under the same license as the BridgeDB project. # # Translators: -# Vikrant Korde <vikrant.korde(a)gmail.com>, 2015 +# Vikrant Korde <vikrant.korde(a)gmail.com>, 2015-2016 msgid "" 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: 2015-12-24 11:15+0000\n" +"PO-Revision-Date: 2016-01-15 05:25+0000\n" "Last-Translator: Vikrant Korde <vikrant.korde(a)gmail.com>\n" "Language-Team: Marathi (http://www.transifex.com/otf/torproject/language/mr/)\n" "MIME-Version: 1.0\n" @@ -95,7 +95,7 @@ msgstr "" #: bridgedb/https/templates/index.html:11 #, python-format msgid "Step %s1%s" -msgstr "" +msgstr "पायरी %s1%s" #: bridgedb/https/templates/index.html:13 #, python-format @@ -105,7 +105,7 @@ msgstr "" #: bridgedb/https/templates/index.html:25 #, python-format msgid "Step %s2%s" -msgstr "" +msgstr "पायरी %s2%s" #: bridgedb/https/templates/index.html:27 #, python-format @@ -115,7 +115,7 @@ msgstr "" #: bridgedb/https/templates/index.html:36 #, python-format msgid "Step %s3%s" -msgstr "" +msgstr "पायरी %s3%s" #: bridgedb/https/templates/index.html:38 #, python-format @@ -192,7 +192,7 @@ msgstr "" #: bridgedb/strings.py:56 #, python-format msgid "Hey, %s!" -msgstr "" +msgstr "ओय, %s!" #: bridgedb/strings.py:57 msgid "Hello, friend!"

1 0

[translation/tor-messenger-privproperties_completed] Update translations for tor-messenger-privproperties_completed
by translation＠torproject.org 14 Jan '16

14 Jan '16

commit dbcfc0135cbae58d36844c88bdd801d7714a0cd2 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Jan 14 19:16:41 2016 +0000 Update translations for tor-messenger-privproperties_completed --- ca/priv.properties | 1 + 1 file changed, 1 insertion(+) diff --git a/ca/priv.properties b/ca/priv.properties new file mode 100644 index 0000000..53ac506 --- /dev/null +++ b/ca/priv.properties @@ -0,0 +1 @@ +priv.account=S'està generant una clau privada per a %S (%S)...

1 0

[tor-commits] [translation/tor-messenger-facebookproperties_completed] Update translations for tor-messenger-facebookproperties_completed
by translation＠torproject.org 14 Jan '16

14 Jan '16

commit 142743df064a40537f0115fc2011410762b0d4cc Author: Translation commit bot <translation(a)torproject.org> Date: Thu Jan 14 19:16:24 2016 +0000 Update translations for tor-messenger-facebookproperties_completed --- ca/facebook.properties | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/ca/facebook.properties b/ca/facebook.properties new file mode 100644 index 0000000..3dc2124 --- /dev/null +++ b/ca/facebook.properties @@ -0,0 +1,7 @@ +# This Source Code Form is subject to the terms of the Mozilla Public +# License, v. 2.0. If a copy of the MPL was not distributed with this +# file, You can obtain one at http://mozilla.org/MPL/2.0/. + +connection.error.useUsernameNotEmailAddress=Feu servir el vostre nom d'usuari del Facebook, no el correu electrònic + +facebook.chat.name=Xat de Facebook

1 0

[translation/tor-messenger-facebookproperties] Update translations for tor-messenger-facebookproperties
by translation＠torproject.org 14 Jan '16

14 Jan '16

commit b1e665bc60f1b8110a23c1144119add4841a52cb Author: Translation commit bot <translation(a)torproject.org> Date: Thu Jan 14 19:16:17 2016 +0000 Update translations for tor-messenger-facebookproperties --- ca/facebook.properties | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ca/facebook.properties b/ca/facebook.properties index aaf7cdc..3dc2124 100644 --- a/ca/facebook.properties +++ b/ca/facebook.properties @@ -2,6 +2,6 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. -connection.error.useUsernameNotEmailAddress=Please use your Facebook username, not an email address +connection.error.useUsernameNotEmailAddress=Feu servir el vostre nom d'usuari del Facebook, no el correu electrònic -facebook.chat.name=Facebook Chat +facebook.chat.name=Xat de Facebook

1 0

[torspec/master] Add my removing-obsolete-clients proposal as 266
by nickm＠torproject.org 14 Jan '16

14 Jan '16

commit 99acfe0bb19f0a0bcb7c1ec4866c817d91ade7c8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Jan 14 11:24:16 2016 -0500 Add my removing-obsolete-clients proposal as 266 --- proposals/000-index.txt | 2 + .../266-removing-current-obsolete-clients.txt | 204 ++++++++++++++++++++ 2 files changed, 206 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 718dd31..411093b 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -186,6 +186,7 @@ Proposals by number: 263 Request to change key exchange protocol for handshake v1.1 [OPEN] 264 Putting version numbers on the Tor subprotocols [OPEN] 265 Load Balancing with Overhead Parameters [DRAFT] +266 Removing current obsolete clients from the Tor network [DRAFT] Proposals by status: @@ -213,6 +214,7 @@ Proposals by status: 259 New Guard Selection Behaviour 260 Rendezvous Single Onion Services 265 Load Balancing with Overhead Parameters + 266 Removing current obsolete clients from the Tor network NEEDS-REVISION: 190 Bridge Client Authorization Based on a Shared Secret OPEN: diff --git a/proposals/266-removing-current-obsolete-clients.txt b/proposals/266-removing-current-obsolete-clients.txt new file mode 100644 index 0000000..3d8a6c3 --- /dev/null +++ b/proposals/266-removing-current-obsolete-clients.txt @@ -0,0 +1,204 @@ +Filename: 266-removing-current-obsolete-clients.txt +Title: Removing current obsolete clients from the Tor network +Author: Nick Mathewson +Created: 14 Jan 2016 +Status: Draft + + +1. Introduction + + Frequently, we find that very old versions of Tor should no longer be + supported on the network. To remove relays is easy enough: we + simply update the directory authorities to stop listing relays that + advertise versions that are too old. + + But to disable clients is harder. + + In another proposal I describe a system for letting future clients go + gracefully obsolete. This proposal explains how we can safely + disable the obsolete clients we have today (and all other client + versions of Tor to date, assuming that they will someday become + obsolete). + +1.1. Why disable clients? + + * Security. Anybody who hasn't updated their Tor client in 5 + years is probably vulnerable to who-knows-what attacks. They + aren't likely to get much anonymity either. + + * Withstand zombie installations. Some Tors out there were once + configured to start-on-boot systems that are now unmaintained. + (See 1.4 below.) They put needless load on the network, and help + nobody. + + * Be able to remove backward-compatibility code. Currently, Tor + supports some truly ancient protocols in order to avoid breaking + ancient versions or Tor. This code needs to be maintained and + tested. Some of it depends on undocumented or deprecated or + non-portable OpenSSL features, and makes it hard to produce a + conforming Tor server implementation. + + * Make it easier to write a conforming Tor relay. If a Tor relay + needs to support every Tor client back through the beginning of + time, that makes it harder to develop and test compatible + implementations. + +1.2. Is this dangerous? + + I don't think so. This proposal describes a way to make older + clients gracefully disconnect from the network only when a majority + of authorities agree that they should. A majority of authorities + already have the ability to inflict arbitrary degrees of sabotage on + the consensus document. + +1.3. History + + The earliest versions of Tor checked the recommended-versions field + in the directory to see whether they should keep running. If they + saw that their version wasn't recommended, they'd shut down. There + was an "IgnoreVersion" option that let you keep running anyway. + + Later, around 2004, the rule changed to "shut down if the version is + _obsolete_", where obsolete was defined as "not recommended, and + older than a version that is recommended." + + In 0.1.1.7-alpha, we made obsolete versions only produce a warning, + and removed IgnoreVersion. (See 3ac34ae3293ceb0f2b8c49.) + + We have still disabled old tor versions. With Tor 0.2.0.5-alpha, + we disabled Tor versions before 0.1.1.6-alpha by having the v1 + authorities begin publishing empty directories only. + + In version 0.2.5.2-alpha, we completely removed support for the v2 + directory protocol used before Tor 0.2.0; there are no longer any v2 + authorities on the network. + + Tor versions before 0.2.1 will currently not progress past fetching + an initial directory, because they believe in a number of directory + authority identity keys that no longer sign the directory. + + Tor versions before 0.2.4 are (lightly) throttled in multihop + circuit creation, because we prioritize ntor CREATE cells over + TAP ones when under load. + +1.4. The big problem: slow zombies and fast zombies + + It would be easy enough to 'disable' old clients by simply removing + server support for the obsolete protocols that they use. But there's + a problem with that approach: what will the clients do when they fail + to make connections, or to extend circuits, or whatever else they are + no longer able to do? + + * Ideally, I'd like such clients to stop functioning _quietly_. If + they stop contacting the network, that would be best. + + * Next best would be if these clients contacted the network only + occasionally and at different times. I'll call these clients + "slow zombies". + + * Worse would be if the clients contact the network frequently, + over and over. I'll call these clients "fast zombies". They + would be at their worst when they focus on authorities, or when + they act in synchrony to all strike at once. + + One goal of this proposal is to ensure that future clients to not + become zombies at all; and that ancient clients become slow zombies + at worst. + + +2. Some ideas that don't work. + +2.1. Dropping connections based on link protocols. + + Tor versions before before 0.2.3.6-alpha use a renegotiation-based + handshake instead of our current handshake. We could detect these + handshakes and close the connection at the relay side if the client + attempts to renegotiate. + + I've tested these changes on versions maint-0.2.0 through + maint-0.2.2. They result in zombies with the following behavior: + + The client contact each authority it knows about, attempting to + make a one-hop directory connection. It fails, detects a failure, + then reconnects more and more slowly ... but one hour later, it + resets its connection schedule and starts again. + + In the steady state this appears to result in about two connections + per client per authority per hour. That is probably too many. + + (Most authorities would be affected: of the authorities that existed + in 0.2.2, gabelmoo has moved and turtles has shut down. The + authorities Faravahar and longclaw are new. The authorities moria1, + tor26, dizum, dannenberg, urras, maatuska and maatuska would all get + hit here.) + + (We could simply remove the renegotiation-detection code entirely, + and reply to all connections with an immediate VERSIONS cell. The + behavior would probably be the same, though.) + + If we throttled connections rather than closing them, we'd only get + one connnection per authority per hour, but authorities would have to + keep open a potentially huge number of sockets. + +2.2. Blocking circuit creation under certain circumstances + + In tor 0.2.5.1-alpha, we began ignoring the UseNTorHandshake option, + and always preferring the ntor handshake where available. + + Unfortunately, we can't simply drop all TAP handshakes, since clients + and relays can still use them in the hidden service protocol. But + we could detect these versions by: + + Looking for use of a TAP handshake from an IP not associated + with with any known relay, or on a connection where the client + did not authenticate. (This could be from a bridge, but clients + don't build circuits that go to an IntroPoint or RendPoint + directly after a bridge.) + + This would still result in clients not having directories, however, + and retrying once an hours. + +3. Ideas that might work + +3.1. Move all authorities to new ports + + We could have each authority known to older clients start listening + for connections at a new port P. We'd forward the old port to the new + port. Once sufficiently many clients were using the new ports, we + could disable the forwarding. + + This would result in the old clients turning into zombies as above, + but they would only be scrabbling at nonexistent ports, causing less + load on the authorities. + + [This proposal would probably be easiest to implement.] + +3.2. Start disabling old link protocols on relays + + We could have new relays start dropping support for the old link + protocols, while maintaining support on the authorities and older + relays. + + The result here would be a degradation of older client performance + over time. They'd still behave zombieishly if the authorities + dropped support, however. + +3.3. Changing the consensus format. + + We could allow 'f' (short for "flag") as a synonym for 's' in + consensus documents. Later, if we want to disable all Tor versions + before today, we can change the consensus algorithm so that the + consensus (or perhaps only the microdesc consensus) is spelled with + 'f' lines instead of 'f' lines. This will create a consensus which + older clients and relays parse as having all nodes down, which will + make them not connect to the network at all. + + We could similarly replace "r" with "n", or replace Running with + Online, or so on. + + In doing this, we could also rename fresh-until and valid-until, so + that new clients would have the real expiration date, and old clients + would see "this consensus never expires". This would prevent them + from downloading new consensuses. + + [This proposal would result in the quietest shutdown.]

1 0

[torspec/master] add proposal 265: Load Balancing with Overhead Parameters
by nickm＠torproject.org 14 Jan '16

14 Jan '16

commit bee44ba05fc37191353177e57b7f6f1d42d8468e Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Jan 14 11:21:40 2016 -0500 add proposal 265: Load Balancing with Overhead Parameters --- proposals/000-index.txt | 6 +- proposals/265-load-balancing-with-overhead.txt | 320 ++++++++++++++++++++++++ 2 files changed, 324 insertions(+), 2 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 7979244..718dd31 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -183,8 +183,9 @@ Proposals by number: 260 Rendezvous Single Onion Services [DRAFT] 261 AEZ for relay cryptography [OPEN] 262 Re-keying live circuits with new cryptographic material [OPEN] -263 Request to change key exchange protocol for handshake [OPEN] +263 Request to change key exchange protocol for handshake v1.1 [OPEN] 264 Putting version numbers on the Tor subprotocols [OPEN] +265 Load Balancing with Overhead Parameters [DRAFT] Proposals by status: @@ -211,6 +212,7 @@ Proposals by status: 257 Refactoring authorities and taking parts offline 259 New Guard Selection Behaviour 260 Rendezvous Single Onion Services + 265 Load Balancing with Overhead Parameters NEEDS-REVISION: 190 Bridge Client Authorization Based on a Shared Secret OPEN: @@ -240,7 +242,7 @@ Proposals by status: 258 Denial-of-service resistance for directory authorities 261 AEZ for relay cryptography 262 Re-keying live circuits with new cryptographic material - 263 Request to change key exchange protocol for handshake + 263 Request to change key exchange protocol for handshake v1.1 264 Putting version numbers on the Tor subprotocols ACCEPTED: 140 Provide diffs between consensuses diff --git a/proposals/265-load-balancing-with-overhead.txt b/proposals/265-load-balancing-with-overhead.txt new file mode 100644 index 0000000..b1d5af6 --- /dev/null +++ b/proposals/265-load-balancing-with-overhead.txt @@ -0,0 +1,320 @@ +Filename: 265-load-balancing-with-overhead.txt +Title: Load Balancing with Overhead Parameters +Authors: Mike Perry +Created: 01 January 2016 +Status: Draft + + +0. Motivation + +In order to properly load balance in the presence of padding and +non-negligible amounts of directory and hidden service traffic, the load +balancing equations in Section 3.8.3 of dir-spec.txt are in need of some +modifications. + +In addition to supporting the idea of overhead, the load balancing +equations can also be simplified by treating Guard+Exit nodes as Exit +nodes in all cases. This causes the 9 sub-cases of the current load +balancing equations to consolidate into a single solution, which also +will greatly simplify the consensus process, and eliminate edge cases +such as #16255[1]. + + +1. Overview + +For padding overhead due to Proposals 251 and 254, and changes to hidden +service path selection in Proposal 247, it will be useful to be able to +specify a pair of parameters that represents the additional traffic +present on Guard and Middle nodes due to these changes. + +The current load balancing equations unfortunately make this excessively +complicated. With overhead factors included, each of the 9 subcases goes +from being a short solution to over a page of calculations for each +subcase. + +Moreover, out of 8751 hourly consensus documents produced in 2015[2], +only 78 of them had a non-zero weight for using Guard+Exit nodes in the +Guard position (weight Wgd), and most of those were well under 1%. The +highest weight for using Guard+Exits in the Guard position recorded in +2015 was 2.62% (on December 10th, 2015). This means clients that chose a +Guard node during that particular hour used only 2.62% of Guard+Exit +flagged nodes' bandwidth when performing a bandwidth-weighted Guard +selection. All clients that chose a Guard node during any other hour did +not consider Guard+Exit nodes at all as potential candidates for their +Guards. + +This indicates that we can greatly simplify these load balancing +equations with little to no change in diversity to the network. + + +2. Simplified Load Balancing Equations + +Recall that the point of the load balancing equations in section 3.8.3 +of dir-spec.txt is to ensure that an equal amount of client traffic is +distributed between Guards, Middles, Exits, and Guard+Exits, where each +flag type can occupy one or more positions in a path. This allocation is +accomplished by solving a system of equations for weights for flag +position selection to ensure equal allocation of client traffic for each +position in a circuit. + +If we ignore overhead for the moment and treat Guard+Exit nodes as Exit +nodes, then this allows the simplified system of equations to become: + + Wgg*G == M + Wme*E + Wmg*G # Guard position == middle position + Wgg*G == Wee*E # Guard position == equals exit position + Wmg*G + Wgg*G == G # Guard allocation weights sum to 1 + Wme*E + Wee*E == E # Exit allocation weights sum to 1 + +This system has four equations and four unknowns, and by transitivity we +ensure that allocated capacity for guard, middle, and exit positions are +all equal. Unlike the equations in 3.8.3 of dir-spec.txt, there are no +special cases to the solutions of these equations because there is no +shortage of constraints and no decision points for allocation based on +scarcity. Thus, there is only one solution. Using SymPy's symbolic +equation solver (see attached script) we obtain: + + E + G + M E + G + M 2*E - G - M 2*G - E - M + Wee: ---------, Wgg: ---------, Wme: -----------, Wmg: ------------ + 3*E 3*G 3*E 3*G + +For the rest of the flags weights, we will do the following: + + Dual-flagged (Guard+Exit) nodes should be treated as Exits: + Wgd = 0, Wmd = Wme, Wed = Wee + + Directory requests use middle weights: + Wbd=Wmd, Wbg=Wmg, Wbe=Wme, Wbm=Wmm + + Handle bridges and strange exit policies: + Wgm=Wgg, Wem=Wee, Weg=Wed + +2.1. Checking for underflow and overflow + +In the old load balancing equations, we required a case-by-case proof to +guard against overflow and underflow, and to decide what to do in the +event of various overflow and underflow conditions[3]. Even still, the +system proved fragile to changes, such as the implementation of Guard +uptime fractions[1]. + +Here, with the simplified equations, we can plainly see that the only +time that a negative weight can arise is in Wme and Wmg, when 2*E < G+M +or when 2*G < E+M. In other words, only when Exits or Guards are scarce. + +Similarly, the only time that a weight exceeding 1.0 can arise is in Wee +and Wgg, which also happens when 2*E < G+M or 2*G < E+M. This means that +parameters will always overflow in pairs (Wee and Wme, and/or Wgg and +Wmg). + +In both these cases, simply clipping the parameters at 1 and 0 provides +as close of a balancing condition as is possible, given the scarcity. + + +3. Load balancing with Overhead Parameters + +Intuitively, overhead due to padding and path selection changes can be +represented as missing capacity in the relevant position. This means +that in the presence of a Guard overhead fraction of G_o and a Middle +overhead fraction of M_o, the total fraction of actual client traffic +carried in those positions is (1-G_o) and (1-M_o), respectively. + +Then, to achieve a balanced allocation of traffic, we consider only the +actual client capacity carried in each position: + + # Guard position minus overhead matches middle position minus overhead: + (1-G_o)*(Wgg*G) == (1-M_o)*(M + Wme*E + Wmg*G) + # Guard position minus overhead matches exit position: + (1-G_o)*(Wgg*G) == 1*(Wee*E) + # Guard weights still sum to 1: + Wmg*G + Wgg*G == G + # Exit weights still sum to 1: + Wme*E + Wee*E == E + +Solving this system with SymPy unfortunately yields some unintuitively +simplified results. For each weight, we first show the SymPy solution, +and then factor that solution into a form analogous to Section 2: + + -(G_o - 1)*(M_o - 1)*(E + G + M) + Wee: --------------------------------------- + E*(G_o + M_o - (G_o - 1)*(M_o - 1) - 2) + + + (1 - G_o)*(1 - M_o)*(E + G + M) + Wee: --------------------------------------- + E*(2 - G_o - M_o + (1 - G_o)*(1 - M_o)) + + + + (M_o - 1)*(E + G + M) + Wgg: --------------------------------------- + G*(G_o + M_o - (G_o - 1)*(M_o - 1) - 2) + + (1 - M_o)*(E + G + M) + Wgg: --------------------------------------- + G*(2 - G_o - M_o + (1 - G_o)*(1- M_o)) + + + + -E*(M_o - 1) + G*(G_o - 1)*(-M_o + 2) - M*(M_o - 1) + Wmg: --------------------------------------------------- + G*(G_o + M_o - (G_o - 1)*(M_o - 1) - 2) + + (2 - M_o)*G*(1 - G_o) - M*(1 - M_o) - E*(1 - M_o) + Wmg: --------------------------------------------------- + G*(2 - G_o - M_o + (1 - G_o )*(1 - M_o)) + + + + E*(G_o + M_o - 2) + G*(G_o - 1)*(M_o - 1) + M*(G_o - 1)*(M_o - 1) + Wme: ----------------------------------------------------------------- + E*(G_o + M_o - (G_o - 1)*(M_o - 1) - 2) + + (2 - G_o - M_o)*E - G*(1 - G_o)*(1 - M_o) - M*(1 - G_o)*(1 - M_o) + Wme: ----------------------------------------------------------------- + E*(2 - G_o - M_o + (1 - G_o)*(1 - M_o)) + + +A simple spot check with G_o = M_o = 0 shows us that with zero overhead, +these solutions become identical to the solutions in Section 2 of this +proposal. + +The final condition that we need to ensure is that these weight values +never become negative or greater than 1.0[3]. + + +3.1. Ensuring against underflow and overflow + +Note that if M_o = G_o = 0, then the solutions and the overflow +conditions are the same as in Section 2. + +Unfortunately, SimPy is unable to solve multivariate inequalities, which +prevents us from directly deriving overflow conditions for each variable +independently (at least easily and without mistakes). Wolfram Alpha is +able to derive closed form solutions to some degree for this, but they +are more complicated than checking the weights for underflow and +overflow directly. + +However, for all overflow and underflow cases, simply warning in the +event of overflow or underflow in the weight variable solutions above is +equivalent anyway. Optimal load balancing given this scarcity should +still result if we clip the resulting solutions to [0, 1.0]. + +It will be wise in the implementation to test the overflow conditions +with M_o = G_o = 0, and with their actual values. This will allow us to +know if the overflow is a result of inherent unbalancing, or due to +input overhead values that are too large (and need to be reduced by, for +example, reducing padding). + + +4. Consensus integration + +4.1. Making use of the Overhead Factors + +In order to keep the consensus process simple on the Directory +Authorities, the overhead parameters represent the combined overhead +from many factors. + +The G_o variable is meant to account for sum of directory overhead, +netflow padding overhead, future two-hop padding overhead, and future +hidden service overhead (for cases where Guard->Middle->Exit circuits +are not used). + +The M_o variable is meant to account for multi-hop padding overhead, +hidden service overhead, as well as an overhead for any future two-hop +directory connections (so that we can consolidate Guards and Directory +guard functionality into a single Guard node). + +There is no need for an E_o variable, because even if there were +Exit-specific overhead, it could be represented by an equivalent +reductions in both G_o and M_o instead. + +Since all relevant padding and directory overhead information is +included in the extra-info documents for each relay, the M_o and G_o +variables could be computed automatically from these extra-info +documents during the consensus process. However, it is probably wiser to +keep humans in the loop and set them manually as consensus parameters +instead, especially since we have not previously had to deal with +serious adversarial consequences from malicious extra-info reporting. + +For clarity, though, it may be a good idea to separate all of the +components of M_o and G_o into separate consensus parameters, and +combine them (via addition) in the final equations. That way it will be +easier to pinpoint the source of any potential overflow issues. This +separation will also enable us to potentially govern padding's +contribution to the overhead via a single tunable value. + +4.2 Integration with Guardfraction + +The GuardFraction changes in Proposal 236 and #16255 should continue to +work with these new equations, so long as the total T, G, and M values +are counted after the GuardFraction multiplier has been applied. + +4.3. Guard flag assignment + +Ideally, the Guard flag assignment process would also not count +Exit-flagged nodes when determining the Guard flag uptime and bandwidth +cutoffs, since we will not be using Guard+Exit flagged nodes as Guard +nodes at all when this change is applied. This will result in more +accurate thresholds for Guard node status, as well as better control +over the true total amount of Guard bandwidth in the consensus. + + + +1. https://trac.torproject.org/projects/tor/ticket/16255 +2. https://collector.torproject.org/archive/relay-descriptors/consensuses/ +3. http://tor-dev.torproject.narkive.com/17H9FewJ/correctness-proof-for-new-ba… + + +Appendix A: SymPy Script for Balancing Equation Solutions +#!/usr/bin/python +from sympy.solvers import solve +from sympy import simplify, Symbol, init_printing, pprint + +# Sympy variable declarations +(G,M,E,D) = (Symbol('G'),Symbol('M'),Symbol('E'),Symbol('D')) +(Wgd,Wmd,Wed,Wme,Wmg,Wgg,Wee) = (Symbol('Wgd'),Symbol('Wmd'),Symbol('Wed'), + Symbol('Wme'),Symbol('Wmg'),Symbol('Wgg'), + Symbol('Wee')) +(G_o, M_o) = (Symbol('G_o'),Symbol('M_o')) + +print "Current Load Balancing Equation Solutions, Case 1:" +pprint(solve( + [Wgg*G + Wgd*D - (M + Wmd*D + Wme*E + Wmg*G), + Wgg*G + Wgd*D - (Wee*E + Wed*D), + Wed*D + Wmd*D + Wgd*D - D, + Wmg*G + Wgg*G - G, + Wme*E + Wee*E - E, + Wmg - Wmd, + 3*Wed - 1], + Wgd, Wmd, Wed, Wme, Wmg, Wgg, Wee)) + +print +print "Case 1 with guard and middle overhead: " +pprint(solve( + [(1-G_o)*(Wgg*G + Wgd*D) - (1-M_o)*(M + Wmd*D + Wme*E + Wmg*G), + (1-G_o)*(Wgg*G + Wgd*D) - (Wee*E + Wed*D), + Wed*D + Wmd*D + Wgd*D - D, + Wmg*G + Wgg*G - G, + Wme*E + Wee*E - E, + Wmg - Wmd, + 3*Wed - 1], + Wgd, Wmd, Wed, Wme, Wmg, Wgg, Wee)) + +print "\n\n" +print "Elimination of combined Guard+Exit flags (no overhead): " +pprint(solve( + [(Wgg*G) - (M + Wme*E + Wmg*G), + (Wgg*G) - 1*(Wee*E), + Wmg*G + Wgg*G - G, + Wme*E + Wee*E - E], + Wme, Wmg, Wgg, Wee)) + +print +print "Elimination of combined Guard+Exit flags (Guard+middle overhead): " +combined = solve( + [(1-G_o)*(Wgg*G) - (1-M_o)*(M + Wme*E + Wmg*G), + (1-G_o)*(Wgg*G) - 1*(Wee*E), + Wmg*G + Wgg*G - G, + Wme*E + Wee*E - E], + Wme, Wmg, Wgg, Wee) +pprint(combined) +

1 0

[torspec/master] In addition to the content, explain the format too
by nickm＠torproject.org 14 Jan '16

14 Jan '16

commit f9e111ead769d48441d99b52039ef0ccbd3f2c62 Author: Sven Herzberg <sven.herzberg(a)cluepunk.com> Date: Wed Jan 13 17:43:53 2016 +0100 In addition to the content, explain the format too The term “X509 certificate” actually only describes one part of the format. Be more explicit to mean DER encoded certificates (in contrast to PEM encoded certifcates). --- tor-spec.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tor-spec.txt b/tor-spec.txt index ee0e511..e85634d 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -559,7 +559,8 @@ see tor-design.pdf. 2: RSA1024 Identity certificate 3: RSA1024 AUTHENTICATE cell link certificate - The certificate format for the above certificate types is X509. + The certificate format for the above certificate types is DER encoded + X509. A CERTS cell may have no more than one certificate of each CertType.

1 0

[tor-browser-bundle/master] Added missing changelogs
by gk＠torproject.org 14 Jan '16

14 Jan '16

commit 6480e726175af3f8a0e6496ee9457f07ad265f7c Author: Georg Koppen <gk(a)torproject.org> Date: Thu Jan 14 13:03:41 2016 +0000 Added missing changelogs --- Bundle-Data/Docs/ChangeLog.txt | 60 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 59 insertions(+), 1 deletion(-) diff --git a/Bundle-Data/Docs/ChangeLog.txt b/Bundle-Data/Docs/ChangeLog.txt index 2e4059e..dbb01bd 100644 --- a/Bundle-Data/Docs/ChangeLog.txt +++ b/Bundle-Data/Docs/ChangeLog.txt @@ -20,7 +20,40 @@ Tor Browser 5.0.7 -- January 7 2016 * Bug 17931: Tor Browser crashes in LogMessageToConsole() * Bug 17875: Discourage editing of torrc-defaults -Tor Browser 5.5a5 -- December 15 2015 +Tor Browser 5.5a5-hardened -- December 18 2015 + * All Platforms + * Update Firefox to 38.5.0esr + * Update Tor to 0.2.7.6 + * Update OpenSSL to 1.0.1q + * Update NoScript to 2.7 + * Update Torbutton to 1.9.4.2 + * Bug 16940: After update, load local change notes + * Bug 16990: Avoid matching '250 ' to the end of node name + * Bug 17565: Tor fundraising campaign donation banner + * Bug 17770: Fix alignments on donation banner + * Bug 17792: Include donation banner in some non en-US Tor Browsers + * Bug 17108: Polish about:tor appearance + * Bug 17568: Clean up tor-control-port.js + * Translation updates + * Update Tor Launcher to 0.2.8.1 + * Bug 17344: Enumerate available language packs for language prompt + * Code clean-up + * Translation updates + * Bug 12516: Compile Tor Browser with -fwrapv + * Bug 9659: Avoid loop due to optimistic data SOCKS code (fix of #3875) + * Bug 15564: Isolate SharedWorkers by first-party domain + * Bug 16940: After update, load local change notes + * Bug 17759: Apply whitelist to local fonts in @font-face (fix of #13313) + * Bug 17747: Add ndnop3 as new default obfs4 bridge + * Bug 17009: Shift and Alt keys leak physical keyboard layout (fix of #15646) + * Bug 17369: Disable RC4 fallback + * Bug 17442: Remove custom updater certificate pinning + * Bug 16863: Avoid confusing error when loop.enabled is false + * Bug 17502: Add a preference for hiding "Open with" on download dialog + * Bug 17446: Prevent canvas extraction by third parties (fixup of #6253) + * Bug 16441: Suppress "Reset Tor Browser" prompt + +Tor Browser 5.5a5 -- December 18 2015 * All Platforms * Update Firefox to 38.5.0esr * Update Tor to 0.2.7.6 @@ -53,6 +86,31 @@ Tor Browser 5.5a5 -- December 15 2015 * OS X * Bug 17661: Whitelist font .Helvetica Neue DeskInterface +Tor Browser 5.0.6 -- December 18 2015 + * All Platforms + * Bug 17877: Tor Browser 5.0.5 is using the wrong Mozilla build tag + +Tor Browser 5.0.5 -- December 15 2015 + * All Platforms + * Update Firefox to 38.5.0esr + * Update Tor to 0.2.7.6 + * Update OpenSSL to 1.0.1q + * Update NoScript to 2.7 + * Update HTTPS Everywhere to 5.1.1 + * Update Torbutton to 1.9.3.7 + * Bug 16990: Avoid matching '250 ' to the end of node name + * Bug 17565: Tor fundraising campaign donation banner + * Bug 17770: Fix alignments on donation banner + * Bug 17792: Include donation banner in some non en-US Tor Browsers + * Translation updates + * Bug 17207: Hide MIME types and plugins from websites + * Bug 16909+17383: Adapt to HTTPS-Everywhere build changes + * Bug 16863: Avoid confusing error when loop.enabled is false + * Bug 17502: Add a preference for hiding "Open with" on download dialog + * Bug 17446: Prevent canvas extraction by third parties (fixup of #6253) + * Bug 16441: Suppress "Reset Tor Browser" prompt + * Bug 17747: Add ndnop3 as new default obfs4 bridge + Tor Browser 5.5a4 -- November 3 2015 * All Platforms * Update Firefox to 38.4.0esr

1 0

[webwml/master] add our 2014 financial docs
by arma＠torproject.org 14 Jan '16

14 Jan '16

commit 8f3e298978f7fe313ffaf210d4c45af68761a86f Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Jan 14 06:49:51 2016 -0500 add our 2014 financial docs --- about/findoc/2014-TorProject-combined-Form990_PC_Audit_Results.pdf | Bin 0 -> 867206 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/about/findoc/2014-TorProject-combined-Form990_PC_Audit_Results.pdf b/about/findoc/2014-TorProject-combined-Form990_PC_Audit_Results.pdf new file mode 100644 index 0000000..f471421 Binary files /dev/null and b/about/findoc/2014-TorProject-combined-Form990_PC_Audit_Results.pdf differ

1 0

[webwml/master] and link to the new financial pdf too
by arma＠torproject.org 14 Jan '16

14 Jan '16

commit 61de6ff092051cebe5b2b8be753609a71768194c Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Jan 14 06:50:06 2016 -0500 and link to the new financial pdf too --- about/en/financials.wml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/about/en/financials.wml b/about/en/financials.wml index d74ec5b..31e4eb0 100644 --- a/about/en/financials.wml +++ b/about/en/financials.wml @@ -13,6 +13,8 @@ <div id="maincol"> <h1>Tor: Financial Reports</h1> <dl> + <dt>Fiscal Year 2014</dt> + <dd><a href="findoc/2014-TorProject-combined-Form990_PC_Audit_Results.pdf">2014 IRS Form 990, State of MA Form PC, and Independent Audit Results</a></dd> <dt>Fiscal Year 2013</dt> <dd><a href="findoc/2013-TorProject-Form990.pdf">2013 IRS Form 990</a></dd> <dd><a href="findoc/2013-TorProject-FormPC.pdf">2013 State of MA Form PC</a></dd>

1 0