| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
We don't store public HsId key in the keystore anymore, so this test is
not needed anymore.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We will soon remove the `KeyMgr::*_with_derived()` functions, so we need
to rewrite `maybe_generate_hsid` using `KeyMgr::get` and
`KeyMgr::generate`.
An important point to note is that `maybe_generate_hsid` no longer
stores the `KP_hs_id` in the key store. The reason we originally put the
`KP_hs_id` in the keystore in the first place was to support offline
HsId mode. However, offline HsId mode was never fully implemented
(#1194), and the decision to put the public part of the HsId in the
keystore is controversial (#1195). We can revisit this decision when we
implement #1194, but for now, we don't need a separate `KP_hs_Id` entry
in the keystore.
|
| |
|
|
| |
We're about to stop storing the public part of the hsid in the keystore.
|
| |
|
|
| |
Closes #1261.
|
| |\
| |
| |
| |
| |
| |
| | |
Add some higher-level documentation for tor-hsservice.
Closes #1228
See merge request tpo/core/arti!1945
|
| | | |
|
| | |
| |
| |
| | |
Closes #1228.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We no longer do replay log locking in IptManager::new. Instead, we
rely on the acquire_instance call in OnionService::launch, which ends
up with ipt_mgr getting an InstanceHandle (which contains a lock
guard).
OnionServiceStateMgr is abolished; it existed to deal with the
generics in the tor_persist::StateMgr API. state_dir has no
generics (other than the T being loaded/stored).
Many places (structs and argument lists) now have state_dir types
which embody a path (or a CheckeDir) along with a lock, rather than
separate path+lock+mistrust.
The creation/startup code uses the new calls from state_dir.
Other more minor changes:
- StartupError::StateDirectoryInaccessible contains tor_persist::Error
- test::create_storage_handles_from_state_dir changed and renamed,
from _from_state_mgr.
- replay::PersistFile's (separate) file lock is now fslock_guard's
|
| | |
| |
| |
| |
| |
| |
| | |
state_dir doesn't have the in-memory dummy implementation,
so there will have to be a real directory here.
Do that now, as prep.
|
| | |
| |
| |
| |
| |
| |
| | |
These are here because that's what you get from the tor_persist
singleton StageMgr API (for type erasure reasons). We're going to
change these to tor_persist::state_dir types and those don't involve
Arcs.
|
| |/
|
|
|
|
| |
This doesn't actually change the behaviour with current Rust. But it
avoids bugs and future changes. Relying on drop order for temporary
directory lifetime seems bad.
|
| |
|
|
|
| |
Introduce the crate, move the code motion, and make minimal necessary
changes.
|
| |
|
|
|
|
|
|
|
|
| |
This method combined two things:
1. the lifetime guard API
2. creation of a subdirectory.
2 is available in raw form too, but not 1. So rename the combined
method to .subdir_used_by and implement it in terms of a new .used_by
which doesn't make a subdirectory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the status of the `OnionService` is derived from the statuses
of its subcomponents. Their initial status will be `Shutdown`, so we
don't need to explicitly initialize it.
As for setting the status when `RunnionOnionService::launch` fails, I
don't think that's necessary: `launch()` returns an error on failure, so
the user will know about it (it doesn't need to watch the stream of
status events to find out it failed).
Part of #1083
|
| |
|
|
| |
Part of #1083
|
| |
|
|
| |
The publisher needs it to notify `OnionService` of status changes.
|
| |
|
|
|
| |
These are now the last uses of these values, so they need the "no
clone" form.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In principle there is a small race with doing this in a separate task:
the reactor and the sweeper might process the new netdir at different
times.
For example, if two netdir updates come in quick succession, and the
sweeper is slower, the sweeper might still be running with the
previous TPs as the publisher is creating keys in the new TPs.
Theoretically, the sweeper might delete keys the reactor has just
generated.
This is also considerably simpler.
|
| |\
| |
| |
| |
| |
| |
| | |
Clarify shutdown behavior when RemoteOnionService is dropped.
Closes #1238 and #1236
See merge request tpo/core/arti!1899
|
| | |
| |
| |
| |
| | |
We don't need to implement this for our first release of onion
services, but we shouldn't ship a function that calls todo!().
|
| | | |
|
| |/
|
|
| |
Followup from !1895.
|
| |\
| |
| |
| |
| | |
tor-hsservice: The publisher should exit when the IPT manager says so.
See merge request tpo/core/arti!1895
|
| | |
| |
| |
| |
| |
| | |
The publisher needs to shut down when
`IptPublisherView::sawait_update()` returns `None`, not pause the
uploads.
|
| | |
| |
| |
| |
| |
| | |
This introduces an internal `OnionServiceStateMgr` trait, which enables
us to store the `StateMgr` inside the `OnionServiceState` (without
having to parameterize `OnionServiceState` on `S: StateMgr`).
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Both `OnionService` and `RunningOnionService` have an `onion_name()`
function. To reduce code duplication, we can move `onion_name()` to a
new `OnionServiceState` struct (which will grow more state management
functions int he future), and make both `*OnionService` structs deref to
it.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
The `StateMgr` is currently only needed in `launch()`, so we don't
really need to store it.
This allows us to unparameterize OnionService.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This a modified version of `tor_hsservice::state::StateMgr::onion_name`.
`tor_hsservice::state::StateMgr` will soon be abolished.
Part of #1220, #1227
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This will enable us to construct non-launched (but configured)
`OnionService`s. We need this, for example, for implementing
the `arti hss` CLI command.
Part of #1227
|
| |/
|
|
| |
Part of #1227
|
| | |
|
| |
|
|
| |
See #1232 for fixing the remaining part of these.
|
| | |
|
| |
|
|
| |
Turns out, we _do_ use this field.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(We can put it back later if we need it.)
|
| | |
|