| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
The establisher has a netdir; the manager generally doesn't. So it
will be convenient for the establisher to provide the linkspecs and so
on.
|
| |
|
|
|
| |
`wait_for_netdir` is needed by the descriptor publisher (to compute the
initial netdir).
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
As with the other APIs here, I'd expect that the implementors will
need to refactor this a lot.
Closes #972.
|
| |
|
|
|
|
|
| |
Taken from @diziet's !1439 and lightly cleaned up so that it
compiles.
Closes #971.
|
| | |
|
| |
|
|
|
|
|
| |
Also, removed some older structures that don't make sense in the
current design.
Closes #970
|
| |
|
|
| |
These are all service-specific, and not client-specific.
|
| |
|
