[or-cvs] r9182: change the v2 dir spec to reflect how the code actually work (tor/trunk/doc)
arma at seul.org
arma at seul.org
Sun Dec 24 05:29:10 UTC 2006
Author: arma
Date: 2006-12-24 00:28:52 -0500 (Sun, 24 Dec 2006)
New Revision: 9182
Modified:
tor/trunk/doc/dir-spec.txt
tor/trunk/doc/dir-voting.txt
Log:
change the v2 dir spec to reflect how the code actually works
with respect to the directory-signature line.
this also resolves nick's issue with how to change the
directory-signature entry in votes. unless there's more to
it than that.
Modified: tor/trunk/doc/dir-spec.txt
===================================================================
--- tor/trunk/doc/dir-spec.txt 2006-12-24 04:09:48 UTC (rev 9181)
+++ tor/trunk/doc/dir-spec.txt 2006-12-24 05:28:52 UTC (rev 9182)
@@ -403,9 +403,11 @@
The signature section contains:
- "directory-signature". A signature of the rest of the document
+ "directory-signature" nickname-of-dirserver NL Signature
+
+ Signature is a signature of this network-status document
(the document up until the signature, including the line
- "directory-signature <nick>\n") using the directory authority's
+ "directory-signature <nick>\n"), using the directory authority's
signing key.
We compress the network status list with zlib before transmitting it.
Modified: tor/trunk/doc/dir-voting.txt
===================================================================
--- tor/trunk/doc/dir-voting.txt 2006-12-24 04:09:48 UTC (rev 9181)
+++ tor/trunk/doc/dir-voting.txt 2006-12-24 05:28:52 UTC (rev 9182)
@@ -19,10 +19,12 @@
This creates a partitioning problem: different clients have different
"most recent" networkstatus sources, and different versions of each
- (since authorities change their statements often). Also, it is very
- redundant: most of the downloaded networkstatus are probably quite
- similar. Worse, the overhead grows as we add more authorities.
+ (since authorities change their statements often).
+ It also creates a scaling problem: most of the downloaded networkstatus
+ are probably quite similar, and the redundancy grows as we add more
+ authorities.
+
So if we have clients only download a single multiply signed consensus
network status statement, we can:
- Save bandwidth.
@@ -65,10 +67,12 @@
If an authority computes the vote wrong, its signature isn't included on
the consensus.
- Clients use a consensus if it is signed by more than half the
- authorities they recognize. If they can't find any such consensus,
- clients either use an older version, or beg the user to adapt the list
- of authorities.
+ Clients use a consensus if it is "trusted": signed by more than half the
+ authorities they recognize. If clients can't find any such consensus,
+ they use the most recent trusted consensus they have. If they don't
+ have any trusted consensus, they warn the user and refuse to operate
+ (and if DirServers is not the default, beg the user to adapt the list
+ of authorities).
2. Details.
@@ -89,12 +93,6 @@
authority's nickname, which MUST be unique among authorities, and
MUST match the nickname in the "directory-signature" entry.
- "directory-signature" -- [XXXX this should be tagged with the nickname
- or identity somehow. -NM] [The bottom of
- http://belegost.mit.edu/tor/status/authority already puts the
- nickname next to it. So we can just fix the spec to require
- this? -RD]
-
Authorities SHOULD cache their most recently generated votes so they
can persist them across restarts. Authorities SHOULD NOT generate
another document until valid-until has passed.
More information about the tor-commits
mailing list