| Commit message (Collapse) | Author | Age |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | | |
This commit does not yet repair section numbering or references.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This subsection is just a placeholder for now.
Also fix section numbers and references.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The vote status document format (3.5) and the process of assigning flags
in a vote (3.6) are both part of the authority operation "exchanging
votes" and not operations on their own. That's why they should be
subsubsections rather than subsections.
This results in the following changes to section numbers:
* 3.5 -> 3.4.1
* 3.6 -> 3.4.2
* 3.7 -> 3.5
* 3.8 -> 3.6
* 3.9 -> 3.7
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This commit does not yet repair section numbering or references.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Phrase subsection title as operation. Also, remove subsubsection implying
that there would be other subsubsections in the future, which is not the
case.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This commit does not yet repair section numbering or references.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Section 3 will describe operations and data formats that are related
to the authority role, and section 4 will specify which operations are
performed by caches. Reflect this in the new section title of section
3, and remove the (already obsolete) overview part listing which
documents are generated by authorities.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The rule we're trying to follow here is that sections are for roles
(client, authority, cache, client) and subsections are for operations
performed by the role. Routers really only perform a single
operation: they periodically upload their descriptors to the
authorities. That's why there should be a single subsection for this
operation.
This effectively substitutes section number parts "2." with "2.1.":
* 2 -> 2.1
* 2.1 -> 2.1.1
* 2.2 -> 2.1.2
* 2.2.1 -> 2.1.2.1
* 2.3 -> 2.1.3
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Prefix all section references with the word "section", and avoid line
breaks between "section[s]" and section numbers.
Searching for section references should now be as easy as (for
example):
grep "section.* 1\.4" dir-spec.txt
Also, while going through section references, lower-case 1 instance of
"Section" to be consistent with the rest and fix 2 broken references.
|
| |/
|
|
| |
https://lists.torproject.org/pipermail/tor-dev/2014-January/006022.html
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Based on review by Karsten, who says:
"""I'm not sure why a) relays with a working DirPort shouldn't
include "dir-cache 1" in their router descriptor and b)
authorities shouldn't assign the "DirCache" flag to relays with a
working DirPort that don't have a "dir-cache 1" line in their
router descriptor. I understand that neither of the two actions
are necessary to make the proposal work. But this could be a
chance to get rid of the DirPort concept entirely and only rely
on "dir-cache 1" and "DirCache" flags in the future."""
|
| |\ |
|
| | | |
|
| |/
|
|
| |
It's not clear that REND_TOKEN refers to the rendezvous cookie.
|
| | |
|
| |
|
|
| |
See rendspec-ng branch in my torspec repository for the revision history.
|
| | |
|
| | |
|
| |
|
|
| |
Based on suggestion from weasel.
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
This closes proposal 157.
|
| | | |
|
| | | |
|
| |/
|
|
| |
Deadening.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When adding an event type we expect spec authors to edit both section 3.4 and
4.1.x. This is error prone...
https://trac.torproject.org/10085
Dropping the redundant listing of event types and simply citing 4.1.x.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our new CONN_BW events' ConnType enumeration is poorly defined...
https://trac.torproject.org/10086
This is just a guess on my part for what it's supposed to be. I have *not*
trudged through the tor code to puzzle out how it actually allocates this
enumeration.
|
| | | |
|
| |/
|
|
| |
Fixes #10090.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
KH is part of the material derived from the KDF during the onion key
process.
In the TAP handshake, KH played two roles: it was sent by the server
towards the client to prove that the server was able to complete the
TAP handshake, AND it was included as part of the
RELAY_ESTABLISH_INTRO message to make it impossible to replay a
RELAY_ESTABLISH_INTRO from one circuit on another circuit.
With the ntor handshake, the first value of KH was removed. But we
still needed a shared, circuit-specific value for hidden service
code to work. This value is taken as an additional 20 bytes from
the KDF. It wasn't documented in the spec, though. Adding it here.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
Also update it with actual decisions and parameters.
|
| |/ |
|
| |\ |
|
| | | |
|
| |/
|
|
| |
Also, add an example of the SOCKS parameters.
|
| | |
|