commit a3fd19302312d44257f175bded3551bc1397ced6 Author: Hans-Christoph Steiner hans@eds.org Date: Tue Nov 26 20:58:54 2019 +0100
fix erroneous header numbering punctuation
The clear standard is trailing "." after each numeric section. This fixes the small handful of outliers. This makes it easy to convert these headers to common markup formats, for example: http://hyperpolyglot.org/lightweight-markup --- bandwidth-file-spec.txt | 4 ++-- cert-spec.txt | 2 +- control-spec.txt | 2 +- dir-list-spec.txt | 6 +++--- dir-spec.txt | 4 ++-- gettor-spec.txt | 6 +++--- glossary.txt | 34 +++++++++++++++++----------------- padding-spec.txt | 2 +- path-spec.txt | 2 +- pt-spec.txt | 2 +- srv-spec.txt | 4 ++-- tor-fw-helper-spec.txt | 2 +- tor-spec.txt | 2 +- 13 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/bandwidth-file-spec.txt b/bandwidth-file-spec.txt index 7564c4c..5a2954c 100644 --- a/bandwidth-file-spec.txt +++ b/bandwidth-file-spec.txt @@ -33,7 +33,7 @@ Nick Mathewson (nickm) Iain Learmonth (irl)
-1.3 Outline +1.3. Outline
The Tor directory protocol (dir-spec.txt [3]) sections 3.4.1 and 3.4.2, use the term bandwidth measurements, to refer to what @@ -644,7 +644,7 @@
2.4. Implementation details
-2.4.1 Writing bandwidth files atomically +2.4.1. Writing bandwidth files atomically
To avoid inconsistent reads, implementations SHOULD write bandwidth files atomically. If the file is transferred from another host, it SHOULD be diff --git a/cert-spec.txt b/cert-spec.txt index 9dde874..e96188b 100644 --- a/cert-spec.txt +++ b/cert-spec.txt @@ -23,7 +23,7 @@ signed document is prefixed with a personalization string, which will be different in each case.
-1.2 Integer encoding +1.2. Integer encoding
Network byte order (big-endian) is used to encode all integer values in Ed25519 certificates unless explicitly specified otherwise. diff --git a/control-spec.txt b/control-spec.txt index e4d6783..ec43516 100644 --- a/control-spec.txt +++ b/control-spec.txt @@ -3932,7 +3932,7 @@ 0.4.0.x): Tor could report having internal paths only; see Section 5.6]
-5.6 Bootstrap phases reported by older versions of Tor +5.6. Bootstrap phases reported by older versions of Tor
These phases were reported by Tor older than 0.4.0.x. For newer versions of Tor, see Section 5.5. diff --git a/dir-list-spec.txt b/dir-list-spec.txt index 56ee0e6..e152c2d 100644 --- a/dir-list-spec.txt +++ b/dir-list-spec.txt @@ -162,7 +162,7 @@ The list header consists of a number of key-value pairs, embedded in C-style comments.
-2.2.1 List Header Format +2.2.1. List Header Format
"/*" SP+ "type=" Keyword SP+ "*/" SP* NL
@@ -234,7 +234,7 @@ Future releases may arbitrarily change the content of this section. Parsers MUST NOT rely on a version increment when the format changes.
-2.3.1 List Generation Format +2.3.1. List Generation Format
In general, parsers MUST NOT rely on the format of this section.
@@ -261,7 +261,7 @@ these lists after parsing them, and applies the DirAuthorityFallbackRate to their weights.)
-2.4.1 Directory Entry Format +2.4.1. Directory Entry Format
If a directory entry does not conform to this format, the entry SHOULD be ignored by parsers. diff --git a/dir-spec.txt b/dir-spec.txt index 2a38d3b..6fa24f1 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2674,7 +2674,7 @@ IPv4 addresses (two /8 networks) were blocked. The list is encoded as described in section 3.8.2.
-3.4.3 Serving bandwidth list files +3.4.3. Serving bandwidth list files
If an authority has used a bandwidth list file to generate a vote document it SHOULD make it available at @@ -2969,7 +2969,7 @@ half of the total authorities, and we do not already have it listed with some <id-Ed>, include it, but do not consider its Ed identity canonical.
-3.8.0.2 Deciding which descriptors to include +3.8.0.2. Deciding which descriptors to include
Deciding which descriptors to include.
diff --git a/gettor-spec.txt b/gettor-spec.txt index 5255b76..f40b298 100644 --- a/gettor-spec.txt +++ b/gettor-spec.txt @@ -30,7 +30,7 @@ GetTor instance. Security and privacy considerations should be described on a per transport basis.
-2.1 Reference implementation +2.1. Reference implementation
We have implemented[0] a compliant GetTor that supports SMTP as a transport.
@@ -43,14 +43,14 @@ it should offer the software as a list of packages and their subsequent descriptions.
-3.1 SMTP transport security considerations +3.1. SMTP transport security considerations
Any GetTor instance that offers SMTP as a transport should optionally implement the checking of DKIM signatures to ensure that email is not forged. Optionally GetTor should take an OpenPGP key from the user and encrypt the response with a blinded message.
-3.2 SMTP transport privacy considerations +3.2. SMTP transport privacy considerations
Any GetTor instance that offers SMTP as a transport must at least store the requester's address for the time that it takes to process a response. This diff --git a/glossary.txt b/glossary.txt index 767080d..6debe20 100644 --- a/glossary.txt +++ b/glossary.txt @@ -18,18 +18,18 @@ citing them authoritatively. ;) "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
-1.0 Commonly used Tor configuration terms +1.0. Commonly used Tor configuration terms
ORPort - Onion Router Port DirPort - Directory Port
-2.0 Tor network components +2.0. Tor network components
- 2.1 Relays, aka OR (onion router) +2.1. Relays, aka OR (onion router)
[Style guide: prefer the term "Relay"]
- 2.1.1 Specific roles +2.1.1. Specific roles
Exit relay: The final hop in an exit circuit before traffic leaves the Tor network to connect to external servers. @@ -57,11 +57,11 @@ citing them authoritatively. ;) Each party builds a three-hop circuit, meeting at the rendezvous point.
- 2.2 Client, aka OP (onion proxy) +2.2. Client, aka OP (onion proxy)
[Style: the "OP" and "onion proxy" terms are deprecated.]
- 2.3 Authorities: +2.3. Authorities:
Directory Authority: Nine total in the Tor network, operated by trusted individuals. Directory authorities define and serve the @@ -79,7 +79,7 @@ citing them authoritatively. ;) the client can ask any directory cache that's listed in the directory information it has.)
- 2.4 Hidden Service: +2.4. Hidden Service:
A hidden service is a server that will only accept incoming connections via the hidden service protocol. Connection @@ -87,7 +87,7 @@ citing them authoritatively. ;) service, allowing the hidden service to receive incoming connections, serve content, etc, while preserving its location anonymity.
- 2.5 Circuit: +2.5. Circuit:
An established path through the network, where cryptographic keys are negotiated using the ntor protocol or TAP (Tor Authentication @@ -104,29 +104,29 @@ citing them authoritatively. ;) network. For example, a client could connect to a hidden service via an internal circuit.
- 2.6 Edge connection: +2.6. Edge connection:
- 2.7 Consensus: The state of the Tor network, published every hour, +2.7. Consensus: The state of the Tor network, published every hour, decided by a vote from the network's directory authorities. Clients fetch the consensus from directory authorities, fallback directories, or directory caches.
- 2.8 Descriptor: Each descriptor represents information about one +2.8. Descriptor: Each descriptor represents information about one relay in the Tor network. The descriptor includes the relay's IP address, public keys, and other data. Relays send descriptors to directory authorities, who vote and publish a summary of them in the network consensus.
-3.0 Tor network protocols +3.0. Tor network protocols
- 3.1 Link handshake +3.1. Link handshake
The link handshake establishes the TLS connection over which two Tor participants will send Tor cells. This handshake also authenticates the participants to each other, possibly using Tor cells.
- 3.2 Circuit handshake +3.2. Circuit handshake
Circuit handshakes establish the hop-by-hop onion encryption that clients use to tunnel their application traffic. The @@ -155,12 +155,12 @@ citing them authoritatively. ;) contains the first part of the TAP or ntor key establishment handshake.
- 3.3 Hidden Service Protocol +3.3. Hidden Service Protocol
- 3.4 Directory Protocol +3.4. Directory Protocol
-4.0 General network definitions +4.0. General network definitions
Leaky Pipe Topology: The ability for the origin of a circuit to address relay cells to be addressed to any hop in the path of a circuit. In Tor, diff --git a/padding-spec.txt b/padding-spec.txt index fe9464c..b3e401a 100644 --- a/padding-spec.txt +++ b/padding-spec.txt @@ -406,7 +406,7 @@ the anonymity and load-balancing implications of their choices. depend on the type of guard used and are not an effective fingerprint for a network/guard-level adversary.
-3.3.2 Client-side onion service introduction circuit obfuscation +3.3.2. Client-side onion service introduction circuit obfuscation
Two circuit padding machines work to hide client-side introduction circuits: one machine at the origin, and one machine at the second hop of the circuit. diff --git a/path-spec.txt b/path-spec.txt index 15d9a3b..a79a4d6 100644 --- a/path-spec.txt +++ b/path-spec.txt @@ -363,7 +363,7 @@ of their choices. Since version 0.2.2.8-alpha, Tor attempts to learn when to give up on circuits based on network conditions.
-2.4.1 Distribution choice and parameter estimation +2.4.1. Distribution choice and parameter estimation
Based on studies of build times, we found that the distribution of circuit build times appears to be a Frechet distribution. However, diff --git a/pt-spec.txt b/pt-spec.txt index 121b8c2..bd4aec6 100644 --- a/pt-spec.txt +++ b/pt-spec.txt @@ -626,7 +626,7 @@ Table of Contents
LOG SEVERITY=debug MESSAGE="Connected to bridge A"
-3.3.5 Pluggable Transport Status Message +3.3.5. Pluggable Transport Status Message
This message is for a client or server PT to be able to signal back to the parent process via stdout or stderr any status messages. diff --git a/srv-spec.txt b/srv-spec.txt index eaf2bda..6916020 100644 --- a/srv-spec.txt +++ b/srv-spec.txt @@ -224,7 +224,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt.
Now we go through the phases of the protocol:
-3.1 Commitment Phase [COMMITMENTPHASE] +3.1. Commitment Phase [COMMITMENTPHASE]
The commit phase lasts from 00:00UTC to 12:00UTC.
@@ -257,7 +257,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt. authoritative commits they have received from each authority. Only one commit per authority must be considered trusted and active at a given time.
-3.2 Reveal Phase +3.2. Reveal Phase
The reveal phase lasts from 12:00UTC to 00:00UTC.
diff --git a/tor-fw-helper-spec.txt b/tor-fw-helper-spec.txt index fdc34b1..f842953 100644 --- a/tor-fw-helper-spec.txt +++ b/tor-fw-helper-spec.txt @@ -20,7 +20,7 @@ tor-fw-helper is a program that implements basic port forwarding requests; it may be used alone or called from Tor itself.
-2.1 Output format +2.1. Output format
2.1.1. Motivation
diff --git a/tor-spec.txt b/tor-spec.txt index 21abfdf..0d8ca10 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1907,7 +1907,7 @@ see tor-design.pdf. RELAY_DATA cell within one increment window. In other word, every 100 cells (increment), random bytes should be introduced in at least one cell.
-7.3.1 SENDME Cell Format +7.3.1. SENDME Cell Format
A circuit-level RELAY_SENDME cell always has its StreamID=0.