commit 18fcb9ab42cca4ce963202a22cd1f93f68ecd57c Author: Nick Mathewson <nickm@torproject.org> Date: Tue Dec 11 09:52:35 2018 -0500 Mark proposal 297-safer-protocol-shutdowns.txt as implemented (#27735) --- proposals/000-index.txt | 4 ++-- proposals/297-safer-protover-shutdowns.txt | 10 +++++++++- tor-spec.txt | 16 ++++++++++++---- 3 files changed, 23 insertions(+), 7 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 9746434..dda8572 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -217,7 +217,7 @@ Proposals by number: 294 TLS 1.3 Migration [DRAFT] 295 Using ADL-GCM for relay cryptography (solving the crypto-tagging attack) [OPEN] 296 Have Directory Authorities expose raw bandwidth list files [OPEN] -297 Relaxing the protover-based shutdown rules [OPEN] +297 Relaxing the protover-based shutdown rules [CLOSED] 298 Putting family lines in canonical form [CLOSED] @@ -249,7 +249,6 @@ Proposals by status: 289 Authenticating sendme cells to mitigate bandwidth attacks 295 Using ADL-GCM for relay cryptography (solving the crypto-tagging attack) 296 Have Directory Authorities expose raw bandwidth list files - 297 Relaxing the protover-based shutdown rules [for 0.3.5.x] ACCEPTED: 188 Bridge Guards and other anti-enumeration defenses 249 Allow CREATE cells with >505 bytes of handshake data @@ -355,6 +354,7 @@ Proposals by status: 283 Move IPv6 ORPorts from microdescriptors to the microdesc consensus [for 0.3.3.x] [in 0.3.3.1-alpha] 284 Hidden Service v3 Control Port 293 Other ways for relays to know when to publish [for 0.3.5] [in 0.4.0.1-alpha] + 297 Relaxing the protover-based shutdown rules [for 0.3.5.x] [in 0.4.0.x] 298 Putting family lines in canonical form [for 0.3.6.x] [in 0.4.0.1-alpha] SUPERSEDED: 112 Bring Back Pathlen Coin Weight diff --git a/proposals/297-safer-protover-shutdowns.txt b/proposals/297-safer-protover-shutdowns.txt index 0307df3..59fbac1 100644 --- a/proposals/297-safer-protover-shutdowns.txt +++ b/proposals/297-safer-protover-shutdowns.txt @@ -2,8 +2,16 @@ Filename: 297-safer-protover-shutdowns.txt Title: Relaxing the protover-based shutdown rules Author: Nick Mathewson Created: 19-Sep-2018 -Status: Open +Status: Closed Target: 0.3.5.x +Implemented-In: 0.4.0.x + +IMPLEMENTATION NOTE: + + We went with the proposed change in section 2. The "release date" is + now updated by the "make update-versions" target whenever the version + number is incremented. Maintainers may also manually set the "release + date" to the future. 1. Introduction diff --git a/tor-spec.txt b/tor-spec.txt index 97d5159..f4d3f53 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1935,19 +1935,27 @@ see tor-design.pdf. 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. + should warn its operator as above. If the consensus is newer than the + date when the software was released or scheduled for release, 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. + - When a client lacks a protocol listed in required-client-protocols, + it should warn the user as above. If the consensus is newer than the + date when the software was released, 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. + Software release dates SHOULD be automatically updated as part of the + release process, to prevent forgetting to move them forward. Software + release dates MAY be manually adjusted by maintainers if necessary. + Starting in version 0.2.9.4-alpha, the initial required protocols for clients that we will Recommend and Require are: