[torspec] branch main updated (c6cf0ad -> b29e64e)
This is an automated email from the git hooks/post-receive script. arma pushed a change to branch main in repository torspec. from c6cf0ad Reindex for prop340. new f9e386e fix a trivial typo new b29e64e proof-reading on prop 266 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: padding-spec.txt | 2 +- proposals/266-removing-current-obsolete-clients.txt | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) -- To stop receiving notification emails like this one, please contact the administrator of this repository.
This is an automated email from the git hooks/post-receive script. arma pushed a commit to branch main in repository torspec. commit f9e386e42623d82954a3f973cf58f6987e66f8f8 Author: Roger Dingledine <arma@torproject.org> AuthorDate: Mon Jun 6 23:46:53 2022 -0400 fix a trivial typo --- padding-spec.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/padding-spec.txt b/padding-spec.txt index ea16d8b..511ea01 100644 --- a/padding-spec.txt +++ b/padding-spec.txt @@ -187,7 +187,7 @@ Table of Contents should use a reasonable proxy for the time at which a cell is sent: for example, when the cell is queued. If this strategy is used, implementations should try to observe the innermost (closest to the wire) - queue that the practically can, and if this queue is already nonempty, + queue that they practically can, and if this queue is already nonempty, padding should not be scheduled until after the queue does become empty.) 2.3. Padding Cell Timeout Distribution Statistics -- To stop receiving notification emails like this one, please contact the administrator of this repository.
This is an automated email from the git hooks/post-receive script. arma pushed a commit to branch main in repository torspec. commit b29e64e5617f83131bc56b5d851c4dd6c27e510d Author: Roger Dingledine <arma@torproject.org> AuthorDate: Mon Jun 6 23:47:18 2022 -0400 proof-reading on prop 266 --- proposals/266-removing-current-obsolete-clients.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/266-removing-current-obsolete-clients.txt b/proposals/266-removing-current-obsolete-clients.txt index bc3592b..a4cc75c 100644 --- a/proposals/266-removing-current-obsolete-clients.txt +++ b/proposals/266-removing-current-obsolete-clients.txt @@ -110,7 +110,7 @@ Superseded-by: 264, 272. 2.1. Dropping connections based on link protocols. - Tor versions before before 0.2.3.6-alpha use a renegotiation-based + Tor versions 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. @@ -137,7 +137,7 @@ Superseded-by: 264, 272. 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 + one connection 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 @@ -210,7 +210,7 @@ A. How to "pull the switch." TIME 0: Implement the client/relay side of proposal 264, backported - to every currently existant Tor version that we still + to every currently extant Tor version that we still support. At the same time, add support for the new consensus type to @@ -227,7 +227,7 @@ A. How to "pull the switch." LATER: - At some point after nearly all clients and relays hav + At some point after nearly all clients and relays have upgraded to the versions released at Time 0 or later, we could make the switchover to publishing the new consensus type. -- To stop receiving notification emails like this one, please contact the administrator of this repository.
participants (1)
-
gitolite role