| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| |
| | |
I still think putting these in svc/ module doesn't make much sense.
Anyway, we can leave them there for now, but I need to get at them
from crate::ipt_establisher.
|
| | | |
|
| | |
| |
| |
| |
| | |
This module is perhaps rather more comprehensive than needed right
now. But I found I kept wanting to change which bits of it I used.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
We don't actually want to distinguish drop from not-drop.
|
| | |
| |
| |
| | |
Needed for ClientCirc::wait_for_close
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
We need a type that holds a rend_handshake::IntroRequest object
internally, but where we don't materialize that object from the
Introduce2 message inside the MsgHandler, since that's more crypto
than we want to put in that task.
|
| | |
| |
| |
| | |
This ensures that the status becomes Faulty when the reactor exits.
|
| | |
| |
| |
| | |
This does not yet do exactly what's documented, but it's closer.
|
| | |
| |
| |
| |
| | |
(This requires us to change the type of the data sent in the
stream. I hope to put it back soon.)
|
| | | |
|
| | |
| |
| |
| |
| | |
This solves some problems but introduces a few new ones; I've tried
to open comments for the latter.
|
| |/ |
|
| |\
| |
| |
| |
| | |
hsservice: Compute rendezvous points correctly.
See merge request tpo/core/arti!1521
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This duplicates some code from hsclient as noted in the comments;
it might be good to reduce this, but the remaining nontrivial
duplication is small, and the logic flow is slightly different
because of the two-step process.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-hsservice errors: Introduce more error types
See merge request tpo/core/arti!1515
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
At the very least, I need FatalError to be distinct:
IptEstablisher::new ought not to fail unless everything is terrible.
Add a the Spawn variant to FatalError (that we'll need soon) and the
Bug variant (which it seems likely we might need).
This also gets rid of the crate-level Result alias.
|
| | | |
| | |
| | |
| | | |
This is what we do elsewhere.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
If the service encouters operational errors, surfacing them here is
not helpful. So these methods ought to work, if they weren't called
erroneously.
|
| | | |
| | |
| | |
| | |
| | | |
The semantics of an Err return from this are unclear. Was it stopped?
And what kind of error might we even return?
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want to change the error return types of many methods, so we need a
way to name `std::result::Result`.
We could use `StdResult`, but, actually, properly distinguishing the
kinds of errors that can occur in various contexts means we don't
actually want a single Error type for the whole crate, so
`crate::Result` is going to go away.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Define drop behaviour of IPT establisher, wrt status watch
See merge request tpo/core/arti!1516
|
| | | | | |
|
| | |_|/
|/| |
| | |
| | | |
I had incorrectly thought that this function was private.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-proto: Make ClientCirc::allow_stream_requests take a HopNum.
Closes #1009
See merge request tpo/core/arti!1519
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For consistency with the other `ClientCirc` APIs,
`ClientCirc::allow_stream_requests` now takes a `HopNum` argument. Upon
receiving an incoming stream request, the reactor now checks if the
request came from the hop specified in `allow_stream_requests` (and if
it came from a different hop, the circuit is closed).
Part of #1009
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The IptEstablisher needs to continuously maintain the IPT even as the
netdir is updated. Whereas, the IPT manager just wants to select the
relay from the netdir once and then only think about the relay
identity.
So it makes sense for the establisher to do necessary lookups of the
relay's ids in the netdir.
|
| |\ \
| |/
|/|
| |
| | |
hsservice: new rend_handshake module
See merge request tpo/core/arti!1512
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This code has most of what we need to go from an INTRODUCE2 message
we've just received to the point where we've connected to the
rendezvous point and we're waiting for a stream of BEGIN messages.
Unfinished pieces are marked with TODO HSS.
Most of #980.
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
| |
The IPT manager is going to want to separate the IptEstablisher
struct (which contains the Drop signal) from the watch receiver.
We could add an accessor to clone the watch, but the copy in the
IptEstablisher would be redundant.
This makes new()'s signature a bit funky but it's an internal method
so I think that's fine.
|
| |
|
|
|
| |
It now supports running in a loop, trying to establish an
introduction point, and reporting status.
|
| | |
|
| |
|
|
| |
This will help with making a keep_established method.
|
| | |
|
| | |
|
| |
|
|
|
| |
Intro points must not send these extensions except in response to a
request that prompts them.
|
| |
|
|
|
|
| |
I had planned to make this code accept extensions of unknown type,
but for now I'm backing out of that plan: the set of extensions we
send influences the set that we're willing to receive.
|
| |
|
|
|
|
|
|
| |
This should be enough now to establish real introduction points,
though there is still a lot of work to do. Part of #976.
This has been rebased and edited to incorporate discussions from
!1465.
|
| | |
|
| |
|
|
|
|
| |
This breakage was caused by increasing the version of tor-keymgr
and independently merging !1452, which added a dependency on the
old version.
|
| |\
| |
| |
| |
| |
| |
| | |
hsservice: Initial data structures and APIs
Closes #972, #971, and #970
See merge request tpo/core/arti!1452
|
| | |
| |
| |
| |
| |
| |
| | |
As with the other APIs here, I'd expect that the implementors will
need to refactor this a lot.
Closes #972.
|
| | | |
|