| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| | |
Now Path is a regular struct with no interior mutability, and we use
Arc::make_mut() for the case when we need to add a hop.
|
| | |
| |
| |
| | |
(We're about to remove the interior mutability from Path.)
|
| | |
| |
| |
| | |
We never actually need to allow these again; see #914
|
| | | |
|
| | |
| |
| |
| |
| | |
This lets us keep the service-side hs-ntor handshake experiemental
for now.
|
| | | |
|
| |/
|
|
|
| |
These are all related to issues that will come up for the service
side of the onion service implementation.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is mostly code movement; you may want to review it with
`--color-moved`.
I'm doing this so we can also use the function in netdoc for
looking up hsdesc authentication.
|
| |
|
|
|
|
|
|
| |
Onion service hops (pointlessly) use SHA3-256 for their
authentication, but they truncate it to 20 bytes (assuming I'm
reading the C right.)
See torspec#204 for clarification here.
|
| |
|
|
| |
Closes #887.
|
| |
|
|
|
| |
I am pretty sure that C tor works around this somehow; we should
figure out how!
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
We want the ability to send the same handshake request in parallel
on multiple introduce circuits. This implies encoding the client
handshake more than once.
(Sadly we can't _actually_ do this in the protocol as it stands,
since the onion service can use a separate KP_hss_ntor for each
introduction point; I'll add a comment to that effect later.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
When we break the 1:1 relationship of message and cell, we'll want
this API to take messages, not cells.
This API is experimental, so we don't need to call it a semver
break.
Closes #881.
|
| |
|
|
|
|
|
|
| |
Formerly we said that it would not return until the handler
was uninstalled. This is incorrect: it returns as soon as the
message is sent and the handler installed.
Closes #885.
|
| |
|
|
|
| |
Fixes
nailing-cargo +stable clippy -p tor-hsclient --all-features --all-targets
|
| |\
| |
| |
| |
| |
| |
| | |
Remove use of arrayref
Closes #872
See merge request tpo/core/arti!1214
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1218#note_2908119
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
I am hoping we can merge this as a "TODO (Diziet)", even though I
think it may be controversial. Ie merging this doesn't represent a
decision to do as I suggest.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also, no longer talk about handlers being "installed". That's not
something that's exposed by this API.
And, say that `send_control_message` can be called again only
after *`send_control_message`* returns, not when `handle_msg` has
returned `UinstallHandler`. IMO this makes more sense.
Explain that we can't maintain a continuous watch while holding a
conversation with the peer. (This is surely an API bug.)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Generated with the following commands:
```
cargo set-version --bump minor -p tor-cell
cargo set-version --bump minor -p tor-linkspec
cargo set-version --bump minor -p tor-proto
cargo set-version --bump minor -p tor-netdoc
cargo set-version --bump minor -p tor-circmgr
cargo set-version --bump patch -p tor-cert
cargo set-version --bump patch -p tor-basic-utils
cargo set-version --bump patch -p tor-rpcbase
cargo set-version --bump patch -p tor-llcrypto
cargo set-version --bump patch -p tor-hscrypto
cargo set-version --bump patch -p tor-checkable
cargo set-version --bump patch -p tor-async-utils
cargo set-version --bump patch -p caret
cargo set-version --bump patch -p fs-mistrust
cargo set-version --bump patch -p safelog
cargo set-version --bump patch -p retry-error
cargo set-version --bump patch -p tor-error
cargo set-version --bump patch -p tor-config
cargo set-version --bump patch -p tor-events
cargo set-version --bump patch -p tor-units
cargo set-version --bump patch -p tor-rtcompat
cargo set-version --bump patch -p tor-rtmock
cargo set-version --bump patch -p tor-protover
cargo set-version --bump patch -p tor-bytes
cargo set-version --bump patch -p tor-socksproto
cargo set-version --bump patch -p tor-consdiff
cargo set-version --bump patch -p tor-netdir
cargo set-version --bump patch -p tor-congestion
cargo set-version --bump patch -p tor-persist
cargo set-version --bump patch -p tor-chanmgr
cargo set-version --bump patch -p tor-ptmgr
cargo set-version --bump patch -p tor-guardmgr
cargo set-version --bump patch -p tor-dirclient
cargo set-version --bump patch -p tor-dirmgr
cargo set-version --bump patch -p tor-hsclient
cargo set-version --bump patch -p tor-hsservice
cargo set-version --bump patch -p arti-client
cargo set-version --bump patch -p arti-rpcserver
cargo set-version --bump patch -p arti-config
cargo set-version --bump patch -p arti-hyper
cargo set-version --bump patch -p arti
cargo set-version --bump patch -p arti-bench
cargo set-version --bump patch -p arti-testing
```
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
Experimental new stream-ctrl feature
Closes #847
See merge request tpo/core/arti!1198
|
| | | |
|
| | |
| |
| |
| | |
There are some weaknesses and problems here; see TODO notes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The idea here is that we want to make DataStream visible to the
RPC system without requiring that the RPC session hold the
DataStream itself (or the Reader, or the Writer). We could solve
this problem by making _all_ the state in the DataStream shared,
but that would introduce unnecessary extra locking in our critical
path.
Instead we're creating the notion of a "control handle" that lets
you manage and observe a stream without actually owning the stream.
Right now the only supported functionality is asking for the
stream's circuit.
Part of #847
|
| | |
| |
| |
| |
| | |
(It doesn't do anything yet. It may eventually become always-on.
But for now let's make this API optional. Part of #847)
|
| | | |
|
| |/
|
|
|
| |
This fixes a warning when building tor-proto without the
`rpc-common` feature.
|
| |\
| |
| |
| |
| |
| |
| | |
tor-proto: Add support for extending circuits through virtual hops.
Closes #726
See merge request tpo/core/arti!1191
|
| | |
| |
| |
| | |
Based on text from @diziet
|
| | | |
|
| | |
| |
| |
| |
| | |
Sadly, this adds a few more `TODO HS` entries, but I think we can
clean them up later after a bit of discussion.
|
| | |
| |
| |
| |
| |
| |
| | |
There are a few new TODO hs comments, though, and an XXXX I'll need
to fix up in the next commit.
Implements #726.
|
| | |
| |
| |
| |
| | |
This is fairly straightforward, thanks to our existing design work
on this code.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
- We make the tor-guardmgr "We have found that {} is usable" line
include the word "guard", otherwise it doesn't appear very useful to a
user in safe logging mode, since the guard gets replaced with
[scrubbed].
- The "Actually got an end cell..." message is downgraded to DEBUG.
|
| | | |
|
| | |
| |
| |
| | |
This is still not the most beautiful interface, but it'll do for now.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
There were two bugs here that made the behavior unlike that of C
tor: we had swapped the MAC inputs, and we had forgotten to include
the public key X in the input.
|
| | |
| |
| |
| | |
We'll want these so we can implement some test vectors.
|