apply contrib/checkSpace.pl to our spec files too.

svn:r5941
This commit is contained in:
Roger Dingledine 2006-02-09 03:44:49 +00:00
parent 31dbb0aec9
commit f534bf33f6
6 changed files with 19 additions and 16 deletions

View File

@ -235,7 +235,6 @@ the message.
Message [NUL-terminated]
3.8. AUTHENTICATE (Type 0x0007)
Sent from the client to the server. Contains a 'magic cookie' to prove

View File

@ -88,7 +88,6 @@ $Id$
Address = ip4-address / ip6-address / hostname (XXXX Define these)
; A "Data" section is a sequence of octets concluded by the terminating
; sequence CRLF "." CRLF. The terminating sequence may not appear in the
; body of the data. Leading periods on lines in the data are escaped with
@ -250,9 +249,10 @@ $Id$
250-OldAddress1=NewAddress1
250 OldAddress2=NewAddress2
containing the source and destination addresses. If request is malformed,
the server replies with "512 syntax error in command argument". If the server
can't fulfill the request, it replies with "451 resource exhausted."
containing the source and destination addresses. If request is
malformed, the server replies with "512 syntax error in command
argument". If the server can't fulfill the request, it replies with
"451 resource exhausted."
The client may decline to provide a body for the original address, and
instead send a special null address ("0.0.0.0" for IPv4, "::0" for IPv6, or
@ -326,15 +326,17 @@ $Id$
"addr-mappings/all"
"addr-mappings/config"
"addr-mappings/cache"
"addr-mappings/control" -- a space-separated list of address mappings, each
in the form of "from-address=to-address". The 'config' key
returns those address mappings set in the configuration; the 'cache'
key returns the mappings in the client-side DNS cache; the 'control'
key returns the mappings set via the control interface; the 'all'
target returns the mappings set through any mechanism.
"addr-mappings/control" -- a space-separated list of address
mappings, each in the form of "from-address=to-address".
The 'config' key returns those address mappings set in the
configuration; the 'cache' key returns the mappings in the
client-side DNS cache; the 'control' key returns the mappings set
via the control interface; the 'all' target returns the mappings
set through any mechanism.
"circuit-status"
A series of lines as for a circuit status event. Each line is of the form:
A series of lines as for a circuit status event. Each line is of
the form:
CircuitID SP CircStatus SP Path CRLF
"stream-status"
@ -694,7 +696,8 @@ $Id$
4.1.8. Descriptors uploaded to us in our role as authoritative dirserver
Syntax:
"650" "+" "AUTHDIR_NEWDESCS" CRLF Action CRLF Message CRLF Descriptor CRLF "." CRLF
"650" "+" "AUTHDIR_NEWDESCS" CRLF Action CRLF Message CRLF
Descriptor CRLF "." CRLF
Action = "ACCEPTED" / "DROPPED" / "REJECTED"
Message = Text
@ -739,3 +742,4 @@ $Id$
should send the sequence [00 00 0D 0A]. This is a valid and unrecognized
command in both protocol versions, and implementations can detect which
error they have received.

View File

@ -511,3 +511,4 @@ TODO:
vice versa). But what about when the client connects to A and B but in
a different order? How bad can it be partitioned based on its
knowledge?

View File

@ -58,3 +58,4 @@ References:
[1] http://archive.socks.permeo.com/protocol/socks4.protocol
[2] http://archive.socks.permeo.com/protocol/socks4a.protocol
[3] SOCKS5: RFC1928

View File

@ -318,7 +318,6 @@ when do we rotate which keys (tls, link, etc)?
derivative key data as
K = H(K0 | [00]) | H(K0 | [01]) | H(K0 | [02]) | ...
The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward
digest Df; the next HASH_LEN 41-60 form the backward digest Db; the next
KEY_LEN 61-76 form Kf, and the final KEY_LEN form Kb. Excess bytes from K
@ -1024,7 +1023,6 @@ A.1. Differences between spec and implementation
B. Things that should change in a later version of the Tor protocol
B.1. ... but which will require backward-incompatible change
- Circuit IDs should be longer.

View File

@ -21,7 +21,6 @@ say, "0.0.8". Our first pre-release would be "0.0.8pre1", followed by
0.0.8. The stable CVS branch would then be versioned "0.0.8.1-cvs",
and any eventual bugfix release would be "0.0.8.1".
The New Way
-----------
@ -44,3 +43,4 @@ Eventually, we release 0.1.1.6. The next patch release is 0.1.1.7.
Between these releases, CVS is versioned with a -cvs tag: after
0.1.1.1-alpha comes 0.1.1.1-alpha-cvs, and so on.