mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 13:13:44 +01:00
apply contrib/checkSpace.pl to our spec files too.
svn:r5941
This commit is contained in:
parent
31dbb0aec9
commit
f534bf33f6
@ -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
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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?
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user