| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
This isn't very much code, but given how long it took me to write
this and make it typecheck, I suspect that others may find it useful
as well.
|
| | |
|
| |
|
|
|
|
| |
This simplifies error handling in `OnionService`.
Closes #1052
|
| |
|
|
|
| |
This doesn't need to be an async_trait now that `Publisher::launch` is
no longer async.
|
| |
|
|
|
|
| |
Fixes #1052
See also the discussion in !1616
|
| |
|
|
|
| |
We want to still have the OnionService kicking around, so we can use
it as a handle.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This fixes a compile error introduced as a result of merging a couple of
conflicting MRs (!1611 and !1604).
This also makes the channel the publisher uses for watching for config
changes receive `Arc<OnionServiceConfig>` (rather than
`OnionServiceConfig`).
|
| |
|
|
| |
We'll use this to implement intro point persistence.
|
| |
|
|
|
|
| |
This has a lot of open questions, and won't work yet, but it
starts to show us the current level of interface mismatch between
our pieces.
|
| |
|
|
| |
This data is all duplicated in other places, or will be.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IntroPointId was RelayIds but that's wrong, because there can be
different IPTs at the same relay - but also because an established IPT
might change its RelayIds.
Use IptLocalId instead, which I think is the type we decided to use
for this, and which is, conveniently, Copy.
And change the variable names to match, everywhere.
Specifically: in places where an intro point is implied (ipt_mgr.rs,
ipt_establish.rs) use the name `lid` everywhere, like in ipt_mgr.rs.
Elsewhere, use `ipt_lid`.
(We could use a longer name, but in that case it should be changed in
ipt_mgr.rs too.)
No actual functional change in this commit.
|
| |
|
|
|
|
| |
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.
|
| |
|