| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
The condition for logging the "generated a new identity.." message was
wrong (`generate_with_derive()` returns `Some(())` if it generated a new
key, and `None` if the key was already present).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We will need the string rerpresentation (minus the TimePeriod or any
other metadata) of `HsSvcKeyRole`s for building `KeyPathPattern`s.
|
| | |
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Initial work on top-level onion service configuration
See merge request tpo/core/arti!1638
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Previously, the descriptor publisher needed the `hsid` for logging
purposes and for deriving the blinded public keys.
This changes the publisher to log the `HsNickname` of the service
instead of the hsid, and to read the blinded keys from the keystore.
|
| | |
| |
| |
| |
| | |
This renames `ReactorState` to `Real`, for consistency with `ipt_mgr`,
which calls the real version of its mockable state `Real`.
|
| |/
|
|
| |
provider).
|
| |
|
|
|
|
| |
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.
|