December 2016 - tor-commits - lists.torproject.org

[translation/tails-greeter-2] Update translations for tails-greeter-2
by translation＠torproject.org 02 Dec '16

02 Dec '16

commit a2da829e6456fd4fac26e3177b7f3d9d59d49855 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 2 23:18:17 2016 +0000 Update translations for tails-greeter-2 --- ru/ru.po | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ru/ru.po b/ru/ru.po index 53bab53..ff5ae1f 100644 --- a/ru/ru.po +++ b/ru/ru.po @@ -10,7 +10,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2016-11-18 00:07+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: Jay_13 <black_buddha666(a)mail.ru>, 2016\n" +"Last-Translator: Oleg Sergeev <djvnsk(a)ya.ru>, 2016\n" "Language-Team: Russian (https://www.transifex.com/otf/teams/1519/ru/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -179,7 +179,7 @@ msgstr "Сохранить дополнительные настройки" #: ../data/greeter.ui.h:35 msgid "toolbutton" -msgstr "" +msgstr "кнопка на панели" #: ../data/greeter.ui.h:36 msgid "Network Configuration" @@ -282,7 +282,7 @@ msgstr "Вы сможете создать зашифрованное храни #: ../tailsgreeter/gui.py:783 msgid "Failed to relock persistent storage." -msgstr "" +msgstr "Не удалось заблокировать постоянное хранилище." #: ../tailsgreeter/gui.py:900 msgid "Bridge & Proxy"

1 0

[translation/tor-launcher-properties_completed] Update translations for tor-launcher-properties_completed
by translation＠torproject.org 02 Dec '16

02 Dec '16

commit b1c8b9fa9e645ea0234777dcfb5811713f155729 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 2 23:16:06 2016 +0000 Update translations for tor-launcher-properties_completed --- fr/torlauncher.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/torlauncher.properties b/fr/torlauncher.properties index 78a78b4..a2bc7cc 100644 --- a/fr/torlauncher.properties +++ b/fr/torlauncher.properties @@ -60,4 +60,4 @@ torlauncher.bootstrapWarning.identity=identité incorrecte torlauncher.bootstrapWarning.timeout=temps de connexion expiré torlauncher.bootstrapWarning.noroute=pas de route vers l'hôte torlauncher.bootstrapWarning.ioerror=erreur de lecture/écriture -torlauncher.bootstrapWarning.pt_missing=un transport câblé est manquant +torlauncher.bootstrapWarning.pt_missing=un transport enfichable est manquant

1 0

[translation/tor-launcher-properties] Update translations for tor-launcher-properties
by translation＠torproject.org 02 Dec '16

02 Dec '16

commit eff01faf51d909a97e4c7c10bf7d1f641f163f33 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 2 23:16:02 2016 +0000 Update translations for tor-launcher-properties --- fr/torlauncher.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/torlauncher.properties b/fr/torlauncher.properties index 78a78b4..a2bc7cc 100644 --- a/fr/torlauncher.properties +++ b/fr/torlauncher.properties @@ -60,4 +60,4 @@ torlauncher.bootstrapWarning.identity=identité incorrecte torlauncher.bootstrapWarning.timeout=temps de connexion expiré torlauncher.bootstrapWarning.noroute=pas de route vers l'hôte torlauncher.bootstrapWarning.ioerror=erreur de lecture/écriture -torlauncher.bootstrapWarning.pt_missing=un transport câblé est manquant +torlauncher.bootstrapWarning.pt_missing=un transport enfichable est manquant

1 0

[translation/bridgedb_completed] Update translations for bridgedb_completed
by translation＠torproject.org 02 Dec '16

02 Dec '16

commit 9a70d13b824efedc0f35f9969dd88057ee49de75 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 2 23:15:11 2016 +0000 Update translations for bridgedb_completed --- fr/LC_MESSAGES/bridgedb.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fr/LC_MESSAGES/bridgedb.po b/fr/LC_MESSAGES/bridgedb.po index fd49795..cd78c51 100644 --- a/fr/LC_MESSAGES/bridgedb.po +++ b/fr/LC_MESSAGES/bridgedb.po @@ -28,7 +28,7 @@ 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: 2016-11-30 21:29+0000\n" +"PO-Revision-Date: 2016-12-02 23:05+0000\n" "Last-Translator: French language coordinator <french.translation(a)rbox.me>\n" "Language-Team: French (http://www.transifex.com/otf/torproject/language/fr/)\n" "MIME-Version: 1.0\n" @@ -243,7 +243,7 @@ msgid "" "difficult for anyone watching your internet traffic to determine that you are\n" "using Tor.\n" "\n" -msgstr "BridgeDB peut fournir des bridges avec plusieurs %stypes de transports enfichables%s, qui peuvent aider à brouiller vos connexions au réseau Tor, ce qui rend plus difficile pour tous ceux qui regardent votre trafic Internet de déterminer que vous utilisez Tor.\n" +msgstr "BridgeDB peut fournir des ponts (bridges) avec plusieurs %stypes de transports enfichables%s, qui peuvent aider à brouiller vos connexions vers le réseau Tor, ce qui rend la surveillance de votre trafic Internet pour déterminer si vous utilisez Tor.\n" #. TRANSLATORS: Please DO NOT translate "Pluggable Transports". #: bridgedb/strings.py:79

1 0

[translation/bridgedb] Update translations for bridgedb
by translation＠torproject.org 02 Dec '16

02 Dec '16

commit 59269a35fb2c53a4aec8a3cf600d94f610c38ee3 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 2 23:15:03 2016 +0000 Update translations for bridgedb --- fr/LC_MESSAGES/bridgedb.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fr/LC_MESSAGES/bridgedb.po b/fr/LC_MESSAGES/bridgedb.po index fd49795..cd78c51 100644 --- a/fr/LC_MESSAGES/bridgedb.po +++ b/fr/LC_MESSAGES/bridgedb.po @@ -28,7 +28,7 @@ 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: 2016-11-30 21:29+0000\n" +"PO-Revision-Date: 2016-12-02 23:05+0000\n" "Last-Translator: French language coordinator <french.translation(a)rbox.me>\n" "Language-Team: French (http://www.transifex.com/otf/torproject/language/fr/)\n" "MIME-Version: 1.0\n" @@ -243,7 +243,7 @@ msgid "" "difficult for anyone watching your internet traffic to determine that you are\n" "using Tor.\n" "\n" -msgstr "BridgeDB peut fournir des bridges avec plusieurs %stypes de transports enfichables%s, qui peuvent aider à brouiller vos connexions au réseau Tor, ce qui rend plus difficile pour tous ceux qui regardent votre trafic Internet de déterminer que vous utilisez Tor.\n" +msgstr "BridgeDB peut fournir des ponts (bridges) avec plusieurs %stypes de transports enfichables%s, qui peuvent aider à brouiller vos connexions vers le réseau Tor, ce qui rend la surveillance de votre trafic Internet pour déterminer si vous utilisez Tor.\n" #. TRANSLATORS: Please DO NOT translate "Pluggable Transports". #: bridgedb/strings.py:79

1 0

[sandboxed-tor-browser/master] Don't use control ports that aren't on the loopback interface.
by yawning＠torproject.org 02 Dec '16

02 Dec '16

commit d8696239faddcb5f2a3bd8335d0bc115f9d884b4 Author: Yawning Angel <yawning(a)schwanenlied.me> Date: Fri Dec 2 18:55:44 2016 +0000 Don't use control ports that aren't on the loopback interface. --- src/cmd/sandboxed-tor-browser/internal/ui/config/config.go | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/cmd/sandboxed-tor-browser/internal/ui/config/config.go b/src/cmd/sandboxed-tor-browser/internal/ui/config/config.go index 7346c81..f119176 100644 --- a/src/cmd/sandboxed-tor-browser/internal/ui/config/config.go +++ b/src/cmd/sandboxed-tor-browser/internal/ui/config/config.go @@ -21,6 +21,7 @@ import ( "encoding/json" "fmt" "io/ioutil" + gonet "net" "os" "path/filepath" "runtime" @@ -414,6 +415,13 @@ func New() (*Config, error) { if net, addr, err := butils.ParseControlPortString(env); err != nil { return nil, fmt.Errorf("invalid control port: %v", err) } else { + // Refuse to use TCP control ports not on the loopback interface. + if net == "tcp" { + host, _, _ := gonet.SplitHostPort(addr) + if !gonet.ParseIP(host).IsLoopback() { + return nil, fmt.Errorf("non-loopback control port: %v", host) + } + } cfg.UseSystemTor = true cfg.SystemTorControlNet = net cfg.SystemTorControlAddr = addr

1 0

[torspec/master] Keep proposals/proposal-status.txt up to date.
by asn＠torproject.org 02 Dec '16

02 Dec '16

commit f930be377f829c63bc85a15df0f6bb7d84223774 Author: George Kadianakis <desnacked(a)riseup.net> Date: Fri Dec 2 12:23:27 2016 -0500 Keep proposals/proposal-status.txt up to date. --- proposals/001-process.txt | 3 ++ proposals/259-guard-selection.txt | 3 +- proposals/260-rend-single-onion.txt | 2 +- proposals/268-guard-selection.txt | 4 +- proposals/proposal-status.txt | 93 +++++++++++++++++++++++++++++++++++++ 5 files changed, 102 insertions(+), 3 deletions(-) diff --git a/proposals/001-process.txt b/proposals/001-process.txt index 6cddb47..ba65211 100644 --- a/proposals/001-process.txt +++ b/proposals/001-process.txt @@ -184,6 +184,9 @@ Proposal status: It isn't going to turn into a spec unless somebody copy-and-pastes it into a new spec for a new subsystem. + Obsolete: This proposal was flawed and has been superseded by another + proposal. See comments in the document for details. + The editors maintain the correct status of proposals, based on rough consensus and their own discretion. diff --git a/proposals/259-guard-selection.txt b/proposals/259-guard-selection.txt index bb5e81c..30bdcfa 100644 --- a/proposals/259-guard-selection.txt +++ b/proposals/259-guard-selection.txt @@ -2,9 +2,10 @@ Filename: 259-guard-selection.txt Title: New Guard Selection Behaviour Author: Isis Lovecruft, George Kadianakis Created: 2015-10-28 -Status: Draft +Status: Obsolete Extends: 241-suspicious-guard-turnover.txt +This proposal was made obsolete by proposal #271. §1. Overview diff --git a/proposals/260-rend-single-onion.txt b/proposals/260-rend-single-onion.txt index 48aa794..9777e0a 100644 --- a/proposals/260-rend-single-onion.txt +++ b/proposals/260-rend-single-onion.txt @@ -2,7 +2,7 @@ Filename: 260-rend-single-onion.txt Title: Rendezvous Single Onion Services Author: Tim Wilson-Brown, John Brooks, Aaron Johnson, Rob Jansen, George Kadianakis, Paul Syverson, Roger Dingledine Created: 2015-10-17 -Status: Draft +Status: Finished 1. Overview diff --git a/proposals/268-guard-selection.txt b/proposals/268-guard-selection.txt index 9277dd8..3417b54 100644 --- a/proposals/268-guard-selection.txt +++ b/proposals/268-guard-selection.txt @@ -2,13 +2,15 @@ Filename: 268-guard-selection.txt Title: New Guard Selection Behaviour Author: Isis Lovecruft, George Kadianakis, [Ola Bini] Created: 2015-10-28 -Status: Draft +Status: Obsolete (Editorial note: this was origianlly written as a revision of proposal 259, but it diverges so substantially that it seemed better to assign it a new number for reference, so that we aren't always talking about "The old 259" and "the new 259". -NM) + This proposal has been obsoleted by proposal #271. + §1. Overview Tor uses entry guards to prevent an attacker who controls some diff --git a/proposals/proposal-status.txt b/proposals/proposal-status.txt index dc0b332..105dca4 100644 --- a/proposals/proposal-status.txt +++ b/proposals/proposal-status.txt @@ -438,6 +438,82 @@ again to remind me! against both website traffic fingerprinting as well as hidden service circuit setup fingerprinting. (9/2015) +255 Controller features to allow for load-balancing hidden services [DRAFT] + + Specifies a technique to improve the scalability of hidden services by + decoupling the introduction and rendezvous functionality so that they can + be performed in separate physical machines. + +256 Key revocation for relays and authorities [OPEN] + + Specifies how directory authorities and relays can revoke compromised + long-term identity keys. + +257 Refactoring authorities and making them more isolated from the net [META] + + Describes a strategy for making directory authorities less vulnerable to + DoS by reducing their exposure to the network. + +258 Denial-of-service resistance for directory authorities [ACCEPTED] + + Describes heuristics that directory authorities can deploy to reduce the + threat of DoS due to large directory connection volumes. + +259 New Guard Selection Behaviour [OBSOLETE] + + Specifies an improved guard-picking algorithm that is capable of defending + against targetted attacks. The proposal has since been obsoleted by + proposal 271. + +260 Rendezvous Single Onion Services [FINISHED] + + Specifies a performance optimization for hidden service that do not care + about location anonymity, so that they build 1-hop circuits instead of + 3-hop circuits to reduce communication latency. + +261 AEZ for relay cryptography [OPEN] + + Specifies a circuit encryption scheme that is resistant to tagging + end-to-end correlation attacks. + +262 Re-keying live circuits with new cryptographic material [OPEN] + + Specifies a way to rekey our circuit crypto so that we allow greater + amounts of encrypted data through them. + +263 Request to change key exchange protocol for handshake v1.2 [OBSOLETE] + + Specifies a quantum-safe key agreement algorithm for Tor circuits. The + proposal was supereceded by proposal 269. + +264 Putting version numbers on the Tor subprotocols [CLOSED] + + Specifies a way for relays to do versioning using their descriptors. In + the past we used the Tor version string for versioning, which is not an + elegant approach. + +265 Load Balancing with Overhead Parameters [ACCEPTED] + + The proposal provides new load balancing equations for Tor which are + capable of taking into account non-standard traffic like padding or + directory and hidden service traffic. + +266 Removing current obsolete clients from the Tor network [DRAFT] + + Specifies ways to disable outdated and insecure Tor clients. + +267 Tor Consensus Transparency [DRAFT] + + Specifies how to apply the certificate transparency approach of TLS to Tor + consensus and vote documents, in an attempt to make attacks more easily + detectable. + +268 New Guard Selection Behaviour [DRAFT] + + Specifies an improved guard-picking algorithm that is capable of defending + against targetted attacks. The proposal has since been obsoleted by + proposal 271. + 269 Transitionally secure hybrid handshakes [DRAFT] Describes a generalised protocol for composing X25519 key exchanges with @@ -448,3 +524,20 @@ again to remind me! Describes a hybrid handshake based on the ntor handshake and the NewHope post-quantum key exchange. Currently needs revision to specify how this proposal depends upon prop#269. + +271 Another algorithm for guard selection [OPEN] + + Specifies an improved guard-picking algorithm that is capable of defending + against targetted attacks. + +272 Listed routers should be Valid, Running, and treated as such [FINISHED] + + This proposal describes a change in how clients understand consensus + flags, and how authorities vote on consensuses. + +273 Exit relay pinning for web services [DRAFT] + + The proposal specifies a scheme for websites to prevent additional + security against malicious exit nodes, by specifying their own set of exit + nodes. +

1 0

[tor/master] Add accessor for inspecting timer callbacks.
by nickm＠torproject.org 02 Dec '16

02 Dec '16

commit e6facbfe7abc50de374300ecd83873ead65b4b04 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 2 12:15:07 2016 -0500 Add accessor for inspecting timer callbacks. --- src/common/timers.c | 14 ++++++++++++++ src/common/timers.h | 2 ++ 2 files changed, 16 insertions(+) diff --git a/src/common/timers.c b/src/common/timers.c index 41b2008..e1ad47b 100644 --- a/src/common/timers.c +++ b/src/common/timers.c @@ -255,6 +255,20 @@ timer_set_cb(tor_timer_t *t, timer_cb_fn_t cb, void *arg) } /** + * Set *cb_out (if provided) to this timer's callback function, + * and *arg_out (if provided) to this timer's callback argument. + */ +void +timer_get_cb(const tor_timer_t *t, + timer_cb_fn_t *cb_out, void **arg_out) +{ + if (cb_out) + *cb_out = t->callback.cb; + if (arg_out) + *arg_out = t->callback.arg; +} + +/** * Schedule the timer t to fire at the current time plus a delay of * delay microseconds. All times are relative to monotime_get(). */ diff --git a/src/common/timers.h b/src/common/timers.h index 5f918f8..c5246a3 100644 --- a/src/common/timers.h +++ b/src/common/timers.h @@ -13,6 +13,8 @@ typedef void (*timer_cb_fn_t)(tor_timer_t *, void *, const struct monotime_t *); tor_timer_t *timer_new(timer_cb_fn_t cb, void *arg); void timer_set_cb(tor_timer_t *t, timer_cb_fn_t cb, void *arg); +void timer_get_cb(const tor_timer_t *t, + timer_cb_fn_t *cb_out, void **arg_out); void timer_schedule(tor_timer_t *t, const struct timeval *delay); void timer_disable(tor_timer_t *t); void timer_free(tor_timer_t *t);

1 0

[torspec/master] prop264: Close the proposal
by nickm＠torproject.org 02 Dec '16

02 Dec '16

commit 72023fc1329ce1eb544d95ca15af8ba78a8ef71c Author: David Goulet <dgoulet(a)torproject.org> Date: Tue Nov 29 11:04:20 2016 -0500 prop264: Close the proposal Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- proposals/000-index.txt | 4 ++-- proposals/264-subprotocol-versions.txt | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index f049d76..6828a64 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -184,7 +184,7 @@ Proposals by number: 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 v1.2 [OBSOLETE] -264 Putting version numbers on the Tor subprotocols [FINISHED] +264 Putting version numbers on the Tor subprotocols [CLOSED] 265 Load Balancing with Overhead Parameters [ACCEPTED] 266 Removing current obsolete clients from the Tor network [DRAFT] 267 Tor Consensus Transparency [DRAFT] @@ -281,7 +281,6 @@ Proposals by status: 217 Tor Extended ORPort Authentication [for 0.2.5.x] 232 Pluggable Transport through SOCKS proxy [in 0.2.6] 235 Stop assigning (and eventually supporting) the Named flag [in 0.2.6, 0.2.7] - 264 Putting version numbers on the Tor subprotocols [in 0.2.9.4-alpha] 272 Listed routers should be Valid, Running, and treated as such [in 0.2.9.3-alpha, 0.2.9.4-alpha] CLOSED: 101 Voting on the Tor Directory System [in 0.2.0.x] @@ -344,6 +343,7 @@ Proposals by status: 238 Better hidden service stats from Tor relays 243 Give out HSDir flag only to relays with Stable flag 250 Random Number Generation During Tor Voting + 264 Putting version numbers on the Tor subprotocols [in 0.2.9.4-alpha] SUPERSEDED: 112 Bring Back Pathlen Coin Weight 113 Simplifying directory authority administration diff --git a/proposals/264-subprotocol-versions.txt b/proposals/264-subprotocol-versions.txt index f183acc..75a1c8f 100644 --- a/proposals/264-subprotocol-versions.txt +++ b/proposals/264-subprotocol-versions.txt @@ -2,7 +2,7 @@ Filename: 264-subprotocol-versions.txt Title: Putting version numbers on the Tor subprotocols Author: Nick Mathewson Created: 6 Jan 2016 -Status: Finished +Status: Closed Implemented-In: 0.2.9.4-alpha

1 0

[torspec/master] Merge proposal 264 to dir-spec and tor-spec
by nickm＠torproject.org 02 Dec '16

02 Dec '16

commit eb4fb3c5851aa77d3fca4ca899e656180e48f5ed Author: David Goulet <dgoulet(a)torproject.org> Date: Tue Nov 29 11:03:41 2016 -0500 Merge proposal 264 to dir-spec and tor-spec Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- dir-spec.txt | 82 +++++++++++++++++++++++++++++++ tor-spec.txt | 155 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 237 insertions(+) diff --git a/dir-spec.txt b/dir-spec.txt index 2417dd0..c701842 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -731,6 +731,32 @@ Present if the router accepts "tunneled" directory requests using a BEGIN_DIR cell over the router's OR port. + "proto" SP Entries NL + + [At most one.] + + Entries = + Entries = Entry + Entries = Entry SP Entries + + Entry = Keyword "=" Values + + Values = Value + Values = Value "," Values + + Value = Int + Value = Int "-" Int + + Int = NON_ZERO_DIGIT + Int = Int DIGIT + + Each 'Entry' in the "proto" line indicates that the Tor relay supports + one or more versions of the protocol in question. Entries should be + sorted by keyword. Values should be numerically ascending within each + entry. (This implies that there should be no overlapping ranges.) + Ranges should be represented as compactly as possible. Ints must be no + more than 2^32 - 1. + 2.1.2. Extra-info document format Extra-info documents consist of the following items: @@ -1425,6 +1451,11 @@ Implementations MUST ignore "id" lines with unrecognized key-types in place of "rsa1024" or "ed25519" + "pr" SP Entries NL + + [At most once.] + + The "proto" element as specified in section 2.1.1. (Note that with microdescriptors, clients do not learn the RSA identity of their routers: they only learn a hash of the RSA identity key. This is @@ -1733,6 +1764,27 @@ Value is the actual shared random value encoded in base64. NumReveals is the number of commits used to generate this SRV. + "recommended-relay-protocols" SP Entries NL + "required-relay-protocols" SP Entries NL + "recommended-client-protocols" SP Entries NL + "required-client-protocols" SP Entries NL + + [At most once for each.] + + The "proto" element as specified in section 2.1.1. + + To vote on these entries, a protocol/version combination is included + only if it is listed by a majority of the voters. + + These lines should be voted on. A majority of votes is sufficient to + make a protocol un-supported. and should require a supermajority of + authorities (2/3) to make a protocol required. The required protocols + should not be torrc-configurable, but rather should be hardwired in + the Tor code. + + The tor-spec.txt section 9 details how a relay and a client should + behave when they encounter these lines in the consensus. + "params" SP [Parameters] NL [At most once] @@ -2010,6 +2062,19 @@ descriptors if they would cause "v" lines to be over 128 characters long. + "pr" SP Entries NL + + [At most once.] + + The "proto" family element as specified in section 2.1.1. + + During voting, authorities copy these lines immediately below the "v" + lines. When a descriptor does not contain a "proto" entry, the + authorities should reconstruct it using the approach described below + in section D. They are included in the consensus using the same rules + as currently used for "v" lines, if a sufficiently late consensus + method is in use. + "w" SP "Bandwidth=" INT [SP "Measured=" INT] [SP "Unmeasured=1"] NL [At most once.] @@ -2575,6 +2640,7 @@ "22" -- Instantiates Ed25519 voting algorithm correctly. "23" -- Adds shared randomness protocol data. "24" -- No longer lists routers that are not Valid in the consensus. + "25" -- Vote on recommended-protocols and required-protocols. Before generating a consensus, an authority must decide which consensus method to use. To do this, it looks for the highest version number @@ -3528,3 +3594,19 @@ C. Converting a curve25519 public key to an ed25519 public key feed it to the ed25519 public key generation algorithm, and see what the sign is. +D. Inferring missing proto lines. + + The directory authorities no longer allow versions of Tor before + 0.2.4.18-rc. But right now, there is no version of Tor in the consensus + before 0.2.4.19. Therefore, we should disallow versions of Tor earlier + than 0.2.4.19, so that we can have the protocol list for all current Tor + versions include: + + Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3 HSRend=1-2 Link=1-4 + LinkAuth=1 Microdesc=1-2 Relay=1-2 + + For Desc, Tor versions before 0.2.7.stable should be taken to have Desc=1 + and versions 0.2.7.stable or later should have Desc=1-2. + + For Microdesc and Cons, Tor versions before 0.2.7.stable should be taken to + support version 1; 0.2.7.stable and later should have 1-2. diff --git a/tor-spec.txt b/tor-spec.txt index ba9782f..e7be756 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1610,3 +1610,158 @@ see tor-design.pdf. cells in both directions on that circuit. Count the amount of memory we recovered towards the total. +9. Subprotocol versioning + + This section specifies the Tor subprotocol versioning. They are broken down + into different types with their current version numbers. Any new version + number should be added to this section. + + The dir-spec.txt details how those versions are encoded. See the + "proto"/"pr" line in a descriptor and the "recommended-relay-protocols", + "required-relay-protocols", "recommended-client-protocols" and + "required-client-protocols" lines in the vote/consensus format. + + Here are the rules a relay and client should follow when encountering a + protocol list in the consensus: + + - When a relay lacks a protocol listed in recommended-relay-protocols, + it should warn its operator that the relay is obsolete. + + - When a relay lacks a protocol listed in required-relay-protocols, it + must not attempt to join the network. + + - When a client lacks a protocol listed in recommended-client-protocols, + it should warn the user that the client is obsolete. + + - When a client lacks a protocol listed in required-client-protocols, it + must not connect to the network. This implements a "safe forward + shutdown" mechanism for zombie clients. + + - If a client or relay has a cached consensus telling it that a given + protocol is required, and it does not implement that protocol, it + SHOULD NOT try to fetch a newer consensus. + + Starting in version 0.2.9.4-alpha, the initial required protocols for + clients that we will Recommend and Require are: + + Cons=1-2 Desc=1-2 DirCache=1 HSDir=2 HSIntro=3 HSRend=1 Link=4 + LinkAuth=1 Microdesc=1-2 Relay=2 + + For relays we will Require: + + Cons=1 Desc=1 DirCache=1 HSDir=2 HSIntro=3 HSRend=1 Link=3-4 + LinkAuth=1 Microdesc=1 Relay=1-2 + + For relays, we will additionally Recommend all protocols which we + recommend for clients. + +9.1. "Link" + + The "link" protocols are those used by clients and relays to initiate and + receive OR connections and to handle cells on OR connections. The "link" + protocol versions correspond 1:1 to those versions. + + Two Tor instances can make a connection to each other only if they have at + least one link protocol in common. + + The current "link" versions are: "1" through "4". See section 4.1 for more + information. All current Tor versions support "1-3"; version from + 0.2.4.11-alpha and on support "1-4". Eventually we will drop "1" and "2". + +9.2. "LinkAuth" + + LinkAuth protocols correspond to varieties of Authenticate cells used for + the v3+ link protocools. + + The current version is "1". + + "2" is unused, and reserved by proposal 244. + + "3" is the ed25519 link handshake of proposal 220. + +9.3. "Relay" + + The "relay" protocols are those used to handle CREATE cells, and those that + handle the various RELAY cell types received after a CREATE cell. (Except, + relay cells used to manage introduction and rendezvous points are managed + with the "HSIntro" and "HSRend" protocols respectively.) + + Current versions are: + + "1" -- supports the TAP key exchange, with all features in Tor 0.2.3. + Support for CREATE and CREATED and CREATE_FAST and CREATED_FAST + and EXTEND and EXTENDED. + + "2" -- supports the ntor key exchange, and all features in Tor + 0.2.4.19. Includes support for CREATE2 and CREATED2 and + EXTEND2 and EXTENDED2. + +9.4. "HSIntro" + + The "HSIntro" protocol handles introduction points. + + "3" -- supports authentication as of proposal 121 in Tor + 0.2.1.6-alpha. + +9.5. "HSRend" + + The "HSRend" protocol handles rendezvous points. + + "1" -- supports all features in Tor 0.0.6. + + "2" -- supports RENDEZVOUS2 cells of arbitrary length as long as they + have 20 bytes of cookie in Tor 0.2.9.1-alpha. + +9.6. "HSDir" + + The "HSDir" protocols are the set of hidden service document types that can + be uploaded to, understood by, and downloaded from a tor relay, and the set + of URLs available to fetch them. + + "1" -- supports all features in Tor 0.2.0.10-alpha. + +9.7. "DirCache" + + The "DirCache" protocols are the set of documents available for download + from a directory cache via BEGIN_DIR, and the set of URLs available to + fetch them. (This excludes URLs for hidden service objects.) + + "1" -- supports all features in Tor 0.2.4.19. + +9.8. "Desc" + + Describes features present or absent in descriptors. + + Most features in descriptors don't require a "Desc" update -- only those + that need to someday be required. For example, someday clients will need + to understand ed25519 identities. + + "1" -- supports all features in Tor 0.2.4.19. + + "2" -- cross-signing with onion-keys, signing with ed25519 + identities. + +9.9. "Microdesc" + + Describes features present or absent in microdescriptors. + + Most features in descriptors don't require a "MicroDesc" update -- only + those that need to someday be required. These correspond more or less with + consensus methods. + + "1" -- consensus methods 9 through 20. + + "2" -- consensus method 21 (adds ed25519 keys to microdescs). + +9.10. "Cons" + + Describes features present or absent in consensus documents. + + Most features in consensus documents don't require a "Cons" update -- only + those that need to someday be required. + + These correspond more or less with consensus methods. + + "1" -- consensus methods 9 through 20. + + "2" -- consensus method 21 (adds ed25519 keys to microdescs).

1 0