- tor-commits - lists.torproject.org

[lego/master] Merge remote-tracking branch 'hackerncoder/support-86'
by kez＠torproject.org 25 Oct '21

25 Oct '21

commit bc96ee58985e63529559653e14b42430ad972c10 Merge: e28f603 4238e9a Author: kez <kez(a)torproject.org> Date: Mon Oct 25 13:29:58 2021 -0700 Merge remote-tracking branch 'hackerncoder/support-86' assets/scss/_tor.scss | 6 ++++++ assets/static/css/bootstrap.css | 6 ++++++ 2 files changed, 12 insertions(+) diff --cc assets/static/css/bootstrap.css index 43a9cb7,81ea9a1..12f731f --- a/assets/static/css/bootstrap.css +++ b/assets/static/css/bootstrap.css @@@ -10081,9 -7969,14 +10081,15 @@@ size .no .sticky { position: sticky; top: 105px; - z-index: 999; } + z-index: 999; +} + @media (max-width: 991px) { + .d-sm-block .sticky { + position: static !important; + } + } + @media (max-width: 767px) { .mobile { display: block !important;

1 0

[torspec/main] Fix typos and cleanup
by nickm＠torproject.org 25 Oct '21

25 Oct '21

commit 29245fd50d1ee3d96cca52154da4d888f34fedea Author: Dimitris Apostolou <dimitris.apostolou(a)icloud.com> Date: Mon Oct 25 23:03:20 2021 +0300 Fix typos and cleanup --- README.md | 2 +- bandwidth-file-spec.txt | 2 +- bridgedb-spec.txt | 2 +- control-spec.txt | 6 +++--- dir-list-spec.txt | 4 ++-- dos-spec.md | 2 +- ext-orport-spec.txt | 6 +++--- guard-spec.txt | 2 +- param-spec.txt | 6 +++--- path-spec.txt | 8 ++++---- pt-spec.txt | 8 ++++---- rend-spec-v3.txt | 24 ++++++++++++------------ srv-spec.txt | 12 ++++++------ tor-spec.txt | 6 +++--- 14 files changed, 45 insertions(+), 45 deletions(-) diff --git a/README.md b/README.md index 1a02a37..bce6bcf 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ the reader to implement a compatible implementation of Tor without ever having to read the Tor source code. The [proposals](/proposals) directory holds our design proposals. These -include historical documents that have now been merged into . For more +include historical documents that have now been merged into. For more information on the proposal process, including an explanation of how to make new proposals, see, see [001-process.txt](/proposals/001-process.txt). diff --git a/bandwidth-file-spec.txt b/bandwidth-file-spec.txt index 58ce83c..d9f4db6 100644 --- a/bandwidth-file-spec.txt +++ b/bandwidth-file-spec.txt @@ -1161,7 +1161,7 @@ B.1. Scaling requirements B.2. A linear scaling method - If scaling is required, here is a simple linear bandwith scaling + If scaling is required, here is a simple linear bandwidth scaling method, which ensures that all bandwidth votes contain approximately the same total bandwidth: diff --git a/bridgedb-spec.txt b/bridgedb-spec.txt index 5ccce92..51f6e5d 100644 --- a/bridgedb-spec.txt +++ b/bridgedb-spec.txt @@ -94,7 +94,7 @@ Table of Contents in the bridge network status parsed earlier or if the bridge does not have the Running flag. BridgeDB discards bridge descriptors which have a different purpose - than "bridge". BridgeDB can be configured to only accept descriptors + than "bridge". BridgeDB can be configured to only accept descriptors with another purpose or not discard descriptors based on purpose at all. BridgeDB memorizes the IP addresses and OR ports of the remaining diff --git a/control-spec.txt b/control-spec.txt index 1feb250..0e2add3 100644 --- a/control-spec.txt +++ b/control-spec.txt @@ -1023,7 +1023,7 @@ Table of Contents "net/listeners/dir" - Listeners for Tor directory protocol, as decribed in dir-spec.txt. + Listeners for Tor directory protocol, as described in dir-spec.txt. "net/listeners/socks" @@ -2699,7 +2699,7 @@ Table of Contents [NOTE: This feature was removed in Tor 0.3.2.1-alpha.] - Tor generates this event when it's an directory authority, and + Tor generates this event when it's a directory authority, and somebody has just uploaded a server descriptor. Syntax: @@ -3736,7 +3736,7 @@ Table of Contents Program = The program path as defined in the *TransportPlugin configuration option. Tor accepts relative and full path. - Transport = This value indicate a hint on what the PT is such as the + Transport = This value indicates a hint on what the PT is such as the name or the protocol used for instance. Message = The status message that the PT sends back to the tor parent process minus the "STATUS" string prefix. Formatted as diff --git a/dir-list-spec.txt b/dir-list-spec.txt index c2d83f4..65af536 100644 --- a/dir-list-spec.txt +++ b/dir-list-spec.txt @@ -358,7 +358,7 @@ Table of Contents recent Tor versions. weight was removed in version 2.0.0, but is documented because it - may be of interest to libraries implementing Tor's fallaback + may be of interest to libraries implementing Tor's fallback behaviour. DQUOTE SP+ key_value DQUOTE SP* NL @@ -457,7 +457,7 @@ Table of Contents Libraries SHOULD consider the potential load on the authorities, and whether other sources can meet their needs. - Libraries that require high-uptime availablility of Tor directory + Libraries that require high-uptime availability of Tor directory information should investigate the following options: * OnionOO: https://metrics.torproject.org/onionoo.html diff --git a/dos-spec.md b/dos-spec.md index d1ca55c..04470b2 100644 --- a/dos-spec.md +++ b/dos-spec.md @@ -46,7 +46,7 @@ kinds of allocation: * Half-open stream records. * Cached onion service descriptors (hsdir only). * Cached DNS resolves (relay only). - * GEOIP-based usage activity statistics. + * GEOIP-based usage activity statistics. Note that directory caches aren't counted, since those are stored on disk and accessed via mmap. diff --git a/ext-orport-spec.txt b/ext-orport-spec.txt index ec88244..6b8f8e1 100644 --- a/ext-orport-spec.txt +++ b/ext-orport-spec.txt @@ -63,14 +63,14 @@ Table of Contents We define one authentication type: SAFE_COOKIE. Its AuthType value is 1. It is based on the client proving to the bridge that - it can access a given "cookie" file on disk. The purpose of + it can access a given "cookie" file on disk. The purpose of authentication is to defend against cross-protocol attacks. If the Extended ORPort is enabled, Tor should regenerate the cookie file on startup and store it in $DataDirectory/extended_orport_auth_cookie. - The location of the cookie can be overriden by using the + The location of the cookie can be overridden by using the configuration file parameter ExtORPortCookieAuthFile, which is defined as: @@ -139,7 +139,7 @@ Table of Contents Status [1 octet] Where, - + Status is 1 if the authentication was successfull. If the + + Status is 1 if the authentication was successful. If the authentication failed, Status is 0. 3. The extended ORPort protocol diff --git a/guard-spec.txt b/guard-spec.txt index e0f61d1..357583b 100644 --- a/guard-spec.txt +++ b/guard-spec.txt @@ -429,7 +429,7 @@ Table of Contents That is: if a non-primary guard becomes confirmed and not every primary guard is confirmed, then the list of primary guards list is regenerated, first from the confirmed guards (as before), and then from any - non-confirmed primary guards guards. + non-confirmed primary guards. Note that {PRIMARY_GUARDS} do not have to be in {USABLE_FILTERED_GUARDS}: they might be unreachable. diff --git a/param-spec.txt b/param-spec.txt index 3cf36b2..f420944 100644 --- a/param-spec.txt +++ b/param-spec.txt @@ -83,7 +83,7 @@ Table of Contents "perconnbwrate" and "perconnbwburst" -- if set, each relay sets up a separate token bucket for every client OR connection, and rate limits - that connection indepedently. Typically left unset, except when used for + that connection independently. Typically left unset, except when used for performance experiments around trac entry 1750. Only honored by relays running Tor 0.2.2.16-alpha and later. (Note that relays running 0.2.2.7-alpha through 0.2.2.14-alpha looked for bwconnrate and @@ -324,7 +324,7 @@ Table of Contents Min: 0. Max: 1. Default: 0. First appeared: 0.2.6 - "guard-lifetime-days" -- Controls guard lifetime. If a unconfirmed + "guard-lifetime-days" -- Controls guard lifetime. If an unconfirmed guard has been sampled more than this many days ago, it should be removed from the guard sample. Min: 1. Max: 3650. Default: 120. @@ -395,7 +395,7 @@ Table of Contents Min: 1. Max: INT32_MAX. Default: 15 First appeared: 0.3.0 - "guard-nonprimary-guard-idle-timeout" -- When trying to confirm + "guard-nonprimary-guard-idle-timeout" -- When trying to confirm nonprimary guards, if a guard doesn't answer for more than this long in seconds, treat it as down. Min: 1. Max: INT32_MAX. Default: 600 diff --git a/path-spec.txt b/path-spec.txt index 6d2df4f..4422be4 100644 --- a/path-spec.txt +++ b/path-spec.txt @@ -192,7 +192,7 @@ Tables of Contents * The fraction of descriptors that we have for nodes with the Guard flag, weighted by their bandwidth for the guard position. * The fraction of descriptors that we have for all nodes, - weighted by their bandwidth for the middle position position. + weighted by their bandwidth for the middle position. * The fraction of descriptors that we have for nodes with the Exit flag, weighted by their bandwidth for the exit position. @@ -491,7 +491,7 @@ Tables of Contents used directly as Xm. Instead of using the mode of discrete build times directly, Tor clients - compute the Xm parameter using the weighted average of the the midpoints + compute the Xm parameter using the weighted average of the midpoints of the 'cbtnummodes' (10) most frequently occurring 10ms histogram bins. Ties are broken in favor of earlier bins (that is, in favor of bins corresponding to shorter build times). @@ -511,7 +511,7 @@ Tables of Contents All times below Xm are counted as having the Xm value via the MAX(), because in Pareto estimators, Xm is supposed to be the lowest value. - However, since clients use mode averaging to estimatre Xm, there can be + However, since clients use mode averaging to estimate Xm, there can be values below our Xm. Effectively, the Pareto estimator then treats that everything smaller than Xm happened at Xm. One can also see that if clients did not do this, alpha could underflow to become negative, which @@ -577,7 +577,7 @@ Tables of Contents to the point 'cbtclosequantile' (default 99) on the Pareto curve, or 60 seconds, whichever is greater. - The actual completion times for these measurements circuits should be + The actual completion times for these measurement circuits should be recorded. Implementations should completely abandon a circuit and ignore the circuit diff --git a/pt-spec.txt b/pt-spec.txt index e43a3f7..05421c1 100644 --- a/pt-spec.txt +++ b/pt-spec.txt @@ -452,7 +452,7 @@ Table of Contents The "VERSION" message is used to signal the Pluggable Transport Specification version (as in "TOR_PT_MANAGED_TRANSPORT_VER") - that the PT proxy will use to configure it's transports and + that the PT proxy will use to configure its transports and communicate with the parent process. The version for the environment values and reply messages @@ -644,7 +644,7 @@ Table of Contents For example, the tor daemon logs those messages at the Severity level and sends them onto the control port using the PT_LOG (see control-spec.txt) - event so any third part can pick them up for debugging. + event so any third party can pick them up for debugging. The format of the message: @@ -670,7 +670,7 @@ Table of Contents STATUS TRANSPORT=Transport <K_1>=<V_1> [<K_2>=<V_2>, ...] - The TRANSPORT value indicate a hint on what the PT is such has the name or + The TRANSPORT value indicates a hint on what the PT is such has the name or the protocol used for instance. As an example, obfs4proxy would use "obfs4". Thus, the Transport value can be anything the PT itself defines and it can be a String or CString (see section 2 in control-spec.txt). @@ -711,7 +711,7 @@ Table of Contents causes cleanup and a graceful shutdown if able). - PT proxies SHOULD attempt to detect when the parent has - terminated (eg: via detecting that it's parent process ID haso + terminated (eg: via detecting that its parent process ID has changed on U*IX systems), and gracefully terminate. 3.5. Pluggable Transport Client Per-Connection Arguments diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 2abc732..6a120eb 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -35,7 +35,7 @@ Table of contents: 2.2.5. Expiring hidden service descriptors [EXPIRE-DESC] 2.2.6. URLs for anonymous uploading and downloading 2.3. Publishing shared random values [PUB-SHAREDRANDOM] - 2.3.1. Client behavior in the absense of shared random values + 2.3.1. Client behavior in the absence of shared random values 2.3.2. Hidden services and changing shared random values 2.4. Hidden service descriptors: outer wrapper [DESC-OUTER] 2.5. Hidden service descriptors: encryption format [HS-DESC-ENC] @@ -457,7 +457,7 @@ Table of contents: To learn the introduction points, clients must decrypt the body of the hidden service descriptor. To do so, clients must know the _unblinded_ - public key of the service, which makes the descriptor unuseable by entities + public key of the service, which makes the descriptor unusable by entities without that knowledge (e.g. HSDirs that don't know the onion address). Also, if optional client authorization is enabled, hidden service @@ -626,7 +626,7 @@ Table of contents: 1.9.1. In even more detail: Client authorization keys [CLIENT-AUTH] When client authorization is enabled, each authorized client of a hidden - service has two more assymetric keypairs which are shared with the hidden + service has two more asymmetric keypairs which are shared with the hidden service. An entity without those keys is not able to use the hidden service. Throughout this document, we assume that these pre-shared keys are exchanged between the hidden service and its clients in a secure out-of-band @@ -746,7 +746,7 @@ Table of contents: HSDirs. The set of responsible HSDirs is determined as specified in [WHERE-HSDESC]. - Specifically, everytime a hidden service publishes its descriptor, it also + Specifically, every time a hidden service publishes its descriptor, it also sets up a timer for a random time between 60 minutes and 120 minutes in the future. When the timer triggers, the hidden service needs to publish its descriptor again to the responsible HSDirs for that time period. @@ -831,7 +831,7 @@ Table of contents: 2.2.4. Using time periods and SRVs to fetch/upload HS descriptors [FETCHUPLOADDESC] Hidden services and clients need to make correct use of time periods (TP) - and shared random values (SRVs) to successfuly fetch and upload + and shared random values (SRVs) to successfully fetch and upload descriptors. Furthermore, to avoid problems with skewed clocks, both clients and services use the 'valid-after' time of a live consensus as a way to take decisions with regards to uploading and fetching descriptors. By using the @@ -894,7 +894,7 @@ Table of contents: As discussed above, services maintain two active descriptors at any time. We call these the "first" and "second" service descriptors. Services rotate - their descriptor everytime they receive a consensus with a valid_after time + their descriptor every time they receive a consensus with a valid_after time past the next SRV calculation time. They rotate their descriptors by discarding their first descriptor, pushing the second descriptor to the first, and rebuilding their second descriptor with the latest data. @@ -1008,7 +1008,7 @@ Table of contents: with a torsion component). The right way for clients to detect such fraudulent addresses (which should - only occur malevolently and never natutally) is to extract the ed25519 + only occur malevolently and never naturally) is to extract the ed25519 public key from the onion address and multiply it by the ed25519 group order and ensure that the result is the ed25519 identity element. For more details, please see [TORSION-REFS]. @@ -1028,7 +1028,7 @@ Table of contents: "shared-rand-previous-value" SP NUM_REVEALS SP VALUE NL "shared-rand-current-value" SP NUM_REVEALS SP VALUE NL -2.3.1. Client behavior in the absense of shared random values +2.3.1. Client behavior in the absence of shared random values If the previous or current shared random value cannot be found in a consensus, then Tor clients and services need to generate their own random @@ -1424,7 +1424,7 @@ Table of contents: MUST be present if "legacy-key" is present. The certificate is a proposal 220 RSA->Ed cross-certificate wrapped - in "-----BEGIN CROSSCERT-----" armor, cross-certifying the the RSA + in "-----BEGIN CROSSCERT-----" armor, cross-certifying the RSA public key found in "legacy-key" using the descriptor signing key. To remain compatible with future revisions to the descriptor format, @@ -1433,7 +1433,7 @@ Table of contents: should ignore ones they do not recognize. Clients who manage to extract the introduction points of the hidden service - can prroceed with the introduction protocol as specified in [INTRO-PROTOCOL]. + can proceed with the introduction protocol as specified in [INTRO-PROTOCOL]. 2.5.3. Deriving hidden service descriptor encryption keys [HS-DESC-ENCRYPTION-KEYS] @@ -1448,7 +1448,7 @@ Table of contents: Here is the key generation logic: - SALT = 16 bytes from H(random), changes each time we rebuld the + SALT = 16 bytes from H(random), changes each time we rebuild the descriptor even if the content of the descriptor hasn't changed. (So that we don't leak whether the intro point list etc. changed) @@ -1615,7 +1615,7 @@ Table of contents: The burst per second of INTRODUCE2 cell relayed to the service. - The PARAM_VALUE size is 8 bytes in order to accomodate 64bit values. + The PARAM_VALUE size is 8 bytes in order to accommodate 64bit values. It MUST match the specified limit for the following PARAM_TYPE: [01] -- Min: 0, Max: 2147483647 diff --git a/srv-spec.txt b/srv-spec.txt index a8bb878..a68ef3e 100644 --- a/srv-spec.txt +++ b/srv-spec.txt @@ -98,7 +98,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt. 2.1. Ten thousand feet view of the protocol Our commit-and-reveal protocol aims to produce a fresh shared random value - everyday at 00:00UTC. The final fresh random value is embedded in the + every day at 00:00UTC. The final fresh random value is embedded in the consensus document at that time. Our protocol has two phases and uses the hourly voting procedure of Tor. @@ -124,11 +124,11 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt. At 00:00UTC, the shared random value is computed from the agreed revealed values and added to the consensus. - This concludes the commit-and-reveal protocol at 00:00UTC everyday. + This concludes the commit-and-reveal protocol every day at 00:00UTC. 2.3. How we use the consensus [CONS] - The produced shared random values needs to be readily available to + The produced shared random values need to be readily available to clients. For this reason we include them in the consensus documents. Every hour the consensus documents need to include the shared random value @@ -403,7 +403,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt. from the COMMIT message. We say that the COMMIT and REVEAL messages correspond, if the comparison was successful. - Pariticipants MUST also check that corresponding COMMIT and REVEAL values + Participants MUST also check that corresponding COMMIT and REVEAL values have the same timestamp value. Authorities should ignore reveal values during the Reveal Phase that don't @@ -578,7 +578,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt. different shared randomness value than the others. We claim that this attack is not particularly fruitful: Alice ends up - having two shared random values to chose from which is a fundamental + having two shared random values to choose from which is a fundamental problem of commit-and-reveal protocols as well (since the last person can always abort or reveal). The attacker can also sabotage the consensus, but there are other ways this can be done with the current voting system. @@ -587,7 +587,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt. First of all, it requires the authority to sabotage two consensuses which will cause quite some noise. Furthermore, the authority needs to send different votes to different auths which is detectable. Like the commit - phase attack, the detection here is to make sure that the commiment values + phase attack, the detection here is to make sure that the commitment values in a vote coming from an authority are always the same for each authority. 6. Discussion diff --git a/tor-spec.txt b/tor-spec.txt index d0d2f73..4467221 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -944,12 +944,12 @@ see tor-design.pdf. TIME (Timestamp) [4 bytes] OTHERADDR (Other OR's address) [variable] ATYPE (Address type) [1 byte] - ALEN (Adress length) [1 byte] + ALEN (Address length) [1 byte] AVAL (Address value in NBO) [ALEN bytes] NMYADDR (Number of this OR's addresses) [1 byte] NMYADDR times: ATYPE (Address type) [1 byte] - ALEN (Adress length) [1 byte] + ALEN (Address length) [1 byte] AVAL (Address value in NBO)) [ALEN bytes] Recognized address types (ATYPE) are: @@ -1849,7 +1849,7 @@ see tor-design.pdf. and relays MUST ignore the payload. In response to a RELAY_BEGIN_DIR cell, relays respond either with a - RELAY_CONNECTED cell on succcess, or a RELAY_END cell on failure. They + RELAY_CONNECTED cell on success, or a RELAY_END cell on failure. They MUST send a RELAY_CONNECTED cell all-zero payload, and clients MUST ignore the payload.

1 0

[torspec/main] Fix grammar in README.md
by nickm＠torproject.org 25 Oct '21

25 Oct '21

commit d3165c9ae0d346288ccb94fbfb831d2686f7abf3 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Oct 25 16:35:46 2021 -0400 Fix grammar in README.md --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index bce6bcf..3ad1db4 100644 --- a/README.md +++ b/README.md @@ -6,9 +6,9 @@ the reader to implement a compatible implementation of Tor without ever having to read the Tor source code. The [proposals](/proposals) directory holds our design proposals. These -include historical documents that have now been merged into. For more -information on the proposal process, including an explanation of how to -make new proposals, see, see +include historical documents that have now been merged into the main +specifications. For more information on the proposal process, including an +explanation of how to make new proposals, see [001-process.txt](/proposals/001-process.txt). ## What you can find here

1 0

[torspec/main] Update proposal index.
by nickm＠torproject.org 25 Oct '21

25 Oct '21

commit c10dd31c0dcf970b8e199e029d56fc483f8a216c Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Oct 25 16:33:21 2021 -0400 Update proposal index. --- proposals/000-index.txt | 4 ++++ proposals/BY_INDEX.md | 2 ++ proposals/README.md | 2 ++ 3 files changed, 8 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index af0c8b1..3ae1776 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -256,6 +256,8 @@ Proposals by number: 333 Vanguards lite [DRAFT] 334 A Directory Authority Flag To Mark Relays As Middle-only [OPEN] 335 An authority-only design for MiddleOnly [OPEN] +336 Randomized schedule for guard retries [OPEN] +337 A simpler way to decide, "Is this guard usable?" [OPEN] Proposals by status: @@ -302,6 +304,8 @@ Proposals by status: 332 Ntor protocol with extra data, version 3 334 A Directory Authority Flag To Mark Relays As Middle-only 335 An authority-only design for MiddleOnly + 336 Randomized schedule for guard retries + 337 A simpler way to decide, "Is this guard usable?" ACCEPTED: 265 Load Balancing with Overhead Parameters [for 0.2.9.x] 275 Stop including meaningful "published" time in microdescriptor consensus [for 0.3.1.x-alpha] diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md index 5e07863..31cc5f8 100644 --- a/proposals/BY_INDEX.md +++ b/proposals/BY_INDEX.md @@ -253,4 +253,6 @@ Below are a list of proposals sorted by their proposal number. See * [`333-vanguards-lite.md`](/proposals/333-vanguards-lite.md): Vanguards lite [DRAFT] * [`334-middle-only-flag.txt`](/proposals/334-middle-only-flag.txt): A Directory Authority Flag To Mark Relays As Middle-only [OPEN] * [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An authority-only design for MiddleOnly [OPEN] +* [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries [OPEN] +* [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" [OPEN] diff --git a/proposals/README.md b/proposals/README.md index 49968f8..737dad1 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -43,6 +43,8 @@ for discussion. * [`332-ntor-v3-with-extra-data.md`](/proposals/332-ntor-v3-with-extra-data.md): Ntor protocol with extra data, version 3 * [`334-middle-only-flag.txt`](/proposals/334-middle-only-flag.txt): A Directory Authority Flag To Mark Relays As Middle-only * [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An authority-only design for MiddleOnly +* [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries +* [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" ## ACCEPTED proposals: slated for implementation

1 0

[torspec/main] Add proposals 336 and 337.
by nickm＠torproject.org 25 Oct '21

25 Oct '21

commit ea41a664476e7bc3690f080fbd3c13e2e32629fc Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Oct 22 17:36:04 2021 -0400 Add proposals 336 and 337. --- proposals/336-randomize-guard-retries.md | 87 +++++++++++++++++++ proposals/337-simpler-guard-usability.md | 138 +++++++++++++++++++++++++++++++ 2 files changed, 225 insertions(+) diff --git a/proposals/336-randomize-guard-retries.md b/proposals/336-randomize-guard-retries.md new file mode 100644 index 0000000..5ee5b71 --- /dev/null +++ b/proposals/336-randomize-guard-retries.md @@ -0,0 +1,87 @@ +``` +Filename: 336-randomize-guard-retries.md +Title: Randomized schedule for guard retries +Author: Nick Mathewson +Created: 2021-10-22 +Status: Open +``` + +# Introduction + +When we notice that a guard isn't working, we don't mark it as retriable +until a certain interval has passed. Currently, these intervals are +fixed, as described in the documentation for `GUARDS_RETRY_SCHED` in +`guard-spec` appendix A.1. Here we propose using a randomized retry +interval instead, based on the same decorrelated-jitter algorithm we use +for directory retries. + +The upside of this approach is that it makes our behavior in +the presence of an unreliable network a bit harder for an attacker to +predict. It also means that if a guard goes down for a while, its +clients will notice that it is up at staggered times, rather than +probing it in lock-step. + +The downside of this approach is that we can, if we get unlucky +enough, completely fail to notice that a preferred guard is online when +we would otherwise have noticed sooner. + +Note that when a guard is marked retriable, it isn't necessarily retried +immediately. Instead, its status is changed from "Unreachable" to +"Unknown", which will cause it to get retried. + +For reference, our previous schedule was: + +``` + {param:PRIMARY_GUARDS_RETRY_SCHED} + -- every 10 minutes for the first six hours, + -- every 90 minutes for the next 90 hours, + -- every 4 hours for the next 3 days, + -- every 9 hours thereafter. + + {param:GUARDS_RETRY_SCHED} -- + -- every hour for the first six hours, + -- every 4 hours for the next 90 hours, + -- every 18 hours for the next 3 days, + -- every 36 hours thereafter. +``` + +# The new algorithm + +We re-use the decorrelated-jitter algorithm from `dir-spec` section 5.5. +The specific formula used to compute the 'i+1'th delay is: + +``` +Delay_{i+1} = MIN(cap, random_between(lower_bound, upper_bound)) +where upper_bound = MAX(lower_bound+1, Delay_i * 3) + lower_bound = MAX(1, base_delay). +``` + +For primary guards, we set base_delay to 30 seconds and cap to 6 hours. + +For non-primary guards, we set base_delay to 10 minutes and cap to 36 +hours. + +(These parameters were selected by simulating the results of using them +until they looked "a bit more aggressive" than the current algorithm, but +not too much.) + +The average behavior for the new primary schedule is: + +``` +First 1.0 hours: 10.14283 attempts. (Avg delay 4m 47.41s) +First 6.0 hours: 19.02377 attempts. (Avg delay 15m 36.95s) +First 96.0 hours: 56.11173 attempts. (Avg delay 1h 40m 3.13s) +First 168.0 hours: 83.67091 attempts. (Avg delay 1h 58m 43.16s) +Steady state: 2h 36m 44.63s between attempts. +``` + +The average behavior for the new non-primary schedule is: + +``` +First 1.0 hours: 3.08069 attempts. (Avg delay 14m 26.08s) +First 6.0 hours: 8.1473 attempts. (Avg delay 35m 25.27s) +First 96.0 hours: 22.57442 attempts. (Avg delay 3h 49m 32.16s) +First 168.0 hours: 29.02873 attempts. (Avg delay 5h 27m 2.36s) +Steady state: 11h 15m 28.47s between attempts. +``` + diff --git a/proposals/337-simpler-guard-usability.md b/proposals/337-simpler-guard-usability.md new file mode 100644 index 0000000..d75c4d8 --- /dev/null +++ b/proposals/337-simpler-guard-usability.md @@ -0,0 +1,138 @@ +``` +Filename: 337-simpler-guard-usability.md +Title: A simpler way to decide, "Is this guard usable?" +Author: Nick Mathewson +Created: 2021-10-22 +Status: Open +``` + +# Introduction + +The current `guard-spec` describes a mechanism for how to behave when +our primary guards are unreachable, and we don't know which other guards +are reachable. This proposal describes a simpler method, currently +implemented in [Arti](https://gitlab.torproject.org/tpo/core/arti/). + +(Note that this method might not actually give different results: its +only advantage is that it is much simpler to implement.) + +## The task at hand + +For illustration, we'll assume that our primary guards are P1, P2, and +P3, and our subsequent guards (in preference order) are G1, G2, G3, and +so on. The status of each guard is Reachable (we think we can connect +to it), Unreachable (we think it's down), or Unknown (we haven't tried +it recently). + +The question becomes, "What should we do when P1, P2, and P3 are +Unreachable, and G1, G2, ... are all Unknown"? + +In this circumstance, we _could_ say that we only build circuits to G1, +wait for them to succeed or fail, and only try G2 if we see that the +circuits to G1 have failed completely. But that delays in the case that +G1 is down. + +Instead, the first time we get a circuit request, we try to build one +circuit to G1. On the next circuit request, if the circuit to G1 isn't +done yet, we launch a circuit to G2 instead. The next request (if the +G1 and G2 circuits are still pending) goes to G3, and so on. But +(here's the critical part!) we don't actually _use_ the circuit to G2 +unless the circuit to G1 fails, and we don't actually _use_ the circuit +to G3 unless the circuits to G1 and G2 both fail. + +This approach causes Tor clients to check the status of multiple +possible guards in parallel, while not actually _using_ any guard until +we're sure that all the guards we'd rather use are down. + +## The current algorithm and its drawbacks + +For the current algorithm, see `guard-spec` section 4.9: circuits are +exploratory if they are not using a primary guard. If such an +exploratory circuit is `waiting_for_better_guard`, then we advance it +(or not) depending on the status of all other _circuits_ using guards that +we'd rather be using. + +In other words, the current algorithm is described in terms of actions +to take with given circuits. + +For Arti (and for other modular Tor implementations), however, this +algorithm is a bit of a pain: it introduces dependencies between the +guard code and the circuit handling code, requiring each one to mess +with the other. + +# Proposal + +I suggest that we describe an alternative algorithm for handing circuits +to non-primary guards, to be used in preference to the current +algorithm. Unlike the existing approach, it isolates the guard logic a +bit better from the circuit logic. + +## Handling exploratory circuits + +When all primary guards are Unreachable, we need to try non-primary +guards. We select the first such guard (in preference order) that is +neither Unreachable nor Pending. Whenever we give out such a guard, if +the guard's status is Unknown, then we call that guard "Pending" until +the attempt to use it succeeds or fails. We remember when the guard +became Pending. + +> Aside: None of the above is a change from our existing specification. + +After completing a circuit, the implementation must check whether +its guard is usable. A guard is usable according to these rules: + +Primary guards are always usable. + +Non-primary guards are usable for a given circuit if every guard earlier +in the preference list is either unsuitable for that circuit +(e.g. because of family restrictions), or marked as Unreachable, or has +been pending for at least `{NONPRIMARY_GUARD_CONNECT_TIMEOUT}`. + +Non-primary guards are unusable for a given circuit if some guard earlier +in the preference list is suitable for the circuit _and_ Reachable. + +Non-primary guards are unusable if they have not become usable after +`{NONPRIMARY_GUARD_IDLE_TIMEOUT}` seconds. + +If a circuit's guard is neither usable nor unusable immediately, the +circuit is not discarded; instead, it is kept (but not used) until it +becomes usable or unusable. + +> I am not 100% sure whether this description produces the same behavior +> as the current guard-spec, but it is simpler to describe, and has +> proven to be simpler to implement. + +## Implications for program design. + +(This entire section is implementation detail to explain why this is a +simplification from the previous algorithm. It is for explanatory +purposes only and is not part of the spec.) + +With this algorithm, we cut down the interaction between the guard code +and the circuit code considerably, but we do not remove it entirely. +Instead, there remains (in Arti terms) a pair of communication channels +between the circuit manager and the guard manager: + + * Whenever a guard is given to the circuit manager, the circuit manager + receives the write end of a single-use channel to + report whether the guard has succeeded or failed. + + * Whenever a non-primary guard is given to the circuit manager, the + circuit receives the read end of a single-use channel that will tell + it whether the guard is usable or unusable. This channel doesn't + report anything until the guard has one status or the other. + +With this design, the circuit manager never needs to look at the list of +guards, and the guard manager never needs to look at the list of +circuits. + +## Subtleties concerning "guard success" + +Note that the above definitions of a Reachable guard depend on reporting +when the _guard_ is successful or failed. This is not necessarily the +same as reporting whether the _circuit_ is successful or failed. For +example, a circuit that fails after the first hop does not necessarily +indicate that there's anything wrong with the guard. Similarly, we can +reasonably conclude that the guard is working (at least somewhat) as +long as we have an open channel to it. +

1 0

[lego/master] Rename two-part language codes to use a dash
by kez＠torproject.org 25 Oct '21

25 Oct '21

commit e28f603b3e0353d6bd85c111ac23681cd9245d47 Author: kez <kez(a)torproject.org> Date: Mon Oct 25 12:57:47 2021 -0700 Rename two-part language codes to use a dash Lektor's this.alt uses a dash instead of an underscore (i.e. es-AR instead of es_AR). --- ...{yec-activist-es_AR(a)2x.png => yec-activist-es-AR(a)2x.png} | Bin ...{yec-activist-es_AR(a)3x.png => yec-activist-es-AR(a)3x.png} | Bin ...{yec-activist-pt_BR(a)2x.png => yec-activist-pt-BR(a)2x.png} | Bin ...{yec-activist-pt_BR(a)3x.png => yec-activist-pt-BR(a)3x.png} | Bin ...{yec-activist-zn_CH(a)2x.png => yec-activist-zn-CH(a)2x.png} | Bin ...{yec-activist-zn_CH(a)3x.png => yec-activist-zn-CH(a)3x.png} | Bin .../svg/{yec-activist-es_AR.svg => yec-activist-es-AR.svg} | 0 .../svg/{yec-activist-pt_BR.svg => yec-activist-pt-BR.svg} | 0 .../svg/{yec-activist-zn_CH.svg => yec-activist-zn-CH.svg} | 0 9 files changed, 0 insertions(+), 0 deletions(-) diff --git a/assets/static/css/images/home/png/yec-activist-es_AR(a)2x.png b/assets/static/css/images/home/png/yec-activist-es-AR(a)2x.png similarity index 100% rename from assets/static/css/images/home/png/yec-activist-es_AR(a)2x.png rename to assets/static/css/images/home/png/yec-activist-es-AR(a)2x.png diff --git a/assets/static/css/images/home/png/yec-activist-es_AR(a)3x.png b/assets/static/css/images/home/png/yec-activist-es-AR(a)3x.png similarity index 100% rename from assets/static/css/images/home/png/yec-activist-es_AR(a)3x.png rename to assets/static/css/images/home/png/yec-activist-es-AR(a)3x.png diff --git a/assets/static/css/images/home/png/yec-activist-pt_BR(a)2x.png b/assets/static/css/images/home/png/yec-activist-pt-BR(a)2x.png similarity index 100% rename from assets/static/css/images/home/png/yec-activist-pt_BR(a)2x.png rename to assets/static/css/images/home/png/yec-activist-pt-BR(a)2x.png diff --git a/assets/static/css/images/home/png/yec-activist-pt_BR(a)3x.png b/assets/static/css/images/home/png/yec-activist-pt-BR(a)3x.png similarity index 100% rename from assets/static/css/images/home/png/yec-activist-pt_BR(a)3x.png rename to assets/static/css/images/home/png/yec-activist-pt-BR(a)3x.png diff --git a/assets/static/css/images/home/png/yec-activist-zn_CH(a)2x.png b/assets/static/css/images/home/png/yec-activist-zn-CH(a)2x.png similarity index 100% rename from assets/static/css/images/home/png/yec-activist-zn_CH(a)2x.png rename to assets/static/css/images/home/png/yec-activist-zn-CH(a)2x.png diff --git a/assets/static/css/images/home/png/yec-activist-zn_CH(a)3x.png b/assets/static/css/images/home/png/yec-activist-zn-CH(a)3x.png similarity index 100% rename from assets/static/css/images/home/png/yec-activist-zn_CH(a)3x.png rename to assets/static/css/images/home/png/yec-activist-zn-CH(a)3x.png diff --git a/assets/static/css/images/home/svg/yec-activist-es_AR.svg b/assets/static/css/images/home/svg/yec-activist-es-AR.svg similarity index 100% rename from assets/static/css/images/home/svg/yec-activist-es_AR.svg rename to assets/static/css/images/home/svg/yec-activist-es-AR.svg diff --git a/assets/static/css/images/home/svg/yec-activist-pt_BR.svg b/assets/static/css/images/home/svg/yec-activist-pt-BR.svg similarity index 100% rename from assets/static/css/images/home/svg/yec-activist-pt_BR.svg rename to assets/static/css/images/home/svg/yec-activist-pt-BR.svg diff --git a/assets/static/css/images/home/svg/yec-activist-zn_CH.svg b/assets/static/css/images/home/svg/yec-activist-zn-CH.svg similarity index 100% rename from assets/static/css/images/home/svg/yec-activist-zn_CH.svg rename to assets/static/css/images/home/svg/yec-activist-zn-CH.svg

1 0

[community/master] Convert untranslatable phrase on homepage to markdown
by kez＠torproject.org 25 Oct '21

25 Oct '21

commit 472628aa24450231c7039e3c81a92a9f5ea7b02c Author: kez <kez(a)torproject.org> Date: Wed Oct 13 09:19:37 2021 -0700 Convert untranslatable phrase on homepage to markdown Context: https://gitlab.torproject.org/tpo/web/community/-/issues/189 --- templates/homepage.html | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/templates/homepage.html b/templates/homepage.html index 361ac35..99f38a1 100644 --- a/templates/homepage.html +++ b/templates/homepage.html @@ -22,9 +22,7 @@ </div> <div class="container"> <div class="row p-5 m-3 border {{ locale.direction }}"> - <p> - {{ _('The Tor Project is committed to fostering an inclusive environment and community. Tor is a place where people should feel safe to engage, share their point of view, and participate.') }} Read our <a href="https://gitweb.torproject.org/community/policies.git/tree/code_of_conduct.t…" title="Code of Conduct" target="_blank">Code of Conduct</a>, <a href="https://gitweb.torproject.org/community/policies.git/tree/social_contract.t…" title="Social Contract" target="_blank">Social Contract</a>, <a href="https://gitweb.torproject.org/community/policies.git/tree/statement_of_valu…" title="Statement of Values" target="_blank">Statement of Values</a> and learn about the <a href="https://gitweb.torproject.org/community/policies.git/tree/community_council…" title="Tor Commmunity Council" target="_blank">Tor Community Council</a>. - </p> + {{ md(_('The Tor Project is committed to fostering an inclusive environment and community. Tor is a place where people should feel safe to engage, share their point of view, and participate. Read our [Code of Conduct](https://gitweb.torproject.org/community/policies.git/tree/code_of_… "Code of Conduct"), [Social Contract](https://gitweb.torproject.org/community/policies.git/tree/social_… "Social Contract"), [Statement of Values](https://gitweb.torproject.org/community/policies.git/tree/statement… "Statement of Values"), and learn about the [Tor Community Council](https://gitweb.torproject.org/community/policies.git/tree/communit… "Tor Community Council").')) }} </div> </div> <footer>

1 0

[donate-static/master] Fix leftover conflict in .gitlab-ci.yml
by kez＠torproject.org 25 Oct '21

25 Oct '21

commit 115218c8314a1e58ead52c43c95df1ad6206d0b6 Author: kez <kez(a)torproject.org> Date: Mon Oct 25 11:34:14 2021 -0700 Fix leftover conflict in .gitlab-ci.yml --- .gitlab-ci.yml | 5 ----- 1 file changed, 5 deletions(-) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 7194027c..0abc34f6 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -1,9 +1,4 @@ -<<<<<<< HEAD image: node:current-bullseye -======= -image: debian:buster-slim - ->>>>>>> e809cc4a6ae50f8734fe7863b8c1a336664fe522 # This template should be usable on any system that's based on apt. # taken from tor gitlabci

1 0

[donate-static/master] Update YEC metacard to newest version
by kez＠torproject.org 25 Oct '21

25 Oct '21

commit 3f124317a837790ded2f8f1b182155fa48793299 Author: Duncan <duncan(a)torproject.org> Date: Mon Oct 25 15:24:30 2021 +0000 Update YEC metacard to newest version --- assets/static/images/donate/yec-metacard.png | Bin 44583 -> 43541 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/assets/static/images/donate/yec-metacard.png b/assets/static/images/donate/yec-metacard.png index a97389f9..d016f2c2 100644 Binary files a/assets/static/images/donate/yec-metacard.png and b/assets/static/images/donate/yec-metacard.png differ

1 0

[tpo/master] Update lego
by gus＠torproject.org 25 Oct '21

25 Oct '21

commit 6b83d2180b003f87f894aa466bba337b5c19e207 Author: gus <gus(a)torproject.org> Date: Mon Oct 25 15:08:54 2021 -0300 Update lego --- lego | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lego b/lego index 9d3943e7..c8ed9e1d 160000 --- a/lego +++ b/lego @@ -1 +1 @@ -Subproject commit 9d3943e71f27eb5c21756106aef9ad0f4398aef2 +Subproject commit c8ed9e1d9cd895cdfb1a9b18822310b40cc93f58

1 0