| Commit message (Collapse) | Author | Age |
| ... | |
| | |
| |
| |
| | |
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.
|
| | |
|
| |
|
|
| |
Spec confusion pointed out by atagar in #9588.
|
| |\ |
|
| | | |
|
| | | |
|
| |\ \ |
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|
| | | |/
| |/| |
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also specify how pluggable transport arguments are passed from the
transport proxy to Tor and then to the bridge authority using
extra-info descriptors.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
These are mainly about how to normalize requests and responses, plus a
few security notes.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Also, make it a bit more extensible, in case we do get multi-packet
responses working in the future.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This was originally a DNSSEC proposal, but the round trip issue makes
it look as though this proposal is not sufficient to implement DNSSEC
for practical use.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In our tor-dev@ discussion Karsten mentioned that we could request at most 96
descriptors at a time when polling by their fingerprints...
https://lists.torproject.org/pipermail/tor-dev/2013-June/005005.html
This is a hardcoded limit in tor, so noting it in our spec...
https://gitweb.torproject.org/tor.git/blob/HEAD:/src/or/routerlist.c#l4435
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The dir-spec describes a dirport method for retrieving all microdescriptors.
While this is a fine idea it was never implemented. Moving the spec portion
that describes this to the attic for now.
https://trac.torproject.org/9271
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Tor moved from v2 to v3 directory information in commit 3ad6dc0e. Prior to that
Tor's 'GETINFO ns/*' options provided v2 information, but since then it's been
v3. For more information see...
https://trac.torproject.org/7953
Technically this is a tor bug, but it happens to be a convenient one so simply
updating our spec. In practice controller authors haven't noticed this
discrepancy because v3 router status entries are a superset of the fields in
v2.
|
| |/ / / |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Mike has expressed on ticket #6872 and irc that he based bandwidth-weights
after the 'params' entry and would like new bandwidth-weights to be permitted.
Changing the spec as follows...
- Allowing for unspecified new 'Keyword=Int32' pairs, keeping the 'params'
requrement that they're sorted.
- Making all values optional, including the current ones. This is a change, but
will give Mike greater flexability and avoid creating a headache of 'these
weights are mandatory in consensus-method X and these other are mandatory in
consensus-method Y'.
|