| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Text from here
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1900#note_2986683
with a few minor fixes.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These two modules are key to the implementation of the locking
protocols.
We must define the locking protocol in terms of underlying OS
semantics (since Unix and Windows have different fs concepts and
different concurrency semantics) and therefore, although we are
sharing some code between the implementations, these modules are what
defines the two protocols.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is not yet "correct", since it will rely on
https://github.com/brunoczim/fslock/pull/15
(Conceivably, it might be better to make the `fslock` crate rm-safe.)
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Expose SRV lifespan info from netdir
Closes #1254
See merge request tpo/core/arti!1903
|
| | | |
| | |
| | |
| | | |
Closes #1254.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This is part of #1254.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
tor-hsservice: Do not store the subcredentials in RendRequestContext.
Closes #1242
See merge request tpo/core/arti!1901
|
| | | |
| | |
| | |
| | | |
Part of #1242
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, the subcredentials were computed in `IptEstablisher::launch`
and stored in `RendRequestContext`. This caused long-running services to
report errors like:
```
WARN tor_hsservice::helpers: Problem while accepting rendezvous request: error: Could not process INTRODUCE request: Introduction handshake was invalid: Circuit-extension handshake authentication failed
```
for clients using newer subcredentials than the ones the service had at
the time the IPT was established.
Fixes #1242
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
The subcredential lookup will be moved to
`IntroRequest::decrypt_from_introduce2`. The error returned on failure
is going to be `IntroRequestError::Subcredentials`.
Part of #1242
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
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!().
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
There was no actual bug here; just some missing comments.
Closes #1236.
|
| |\| |
| |/
|/|
| |
| |
| |
| | |
Do not reject INTRO_ESTABLISHED messages with extensions
Closes #1238
See merge request tpo/core/arti!1898
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The spec says that we should ignore unrecognized extensions.
Per discussion at torspec#249, this is still correct.
Additionally, this commit moves responsibility for checking
INTRO_ESTABLISHED messages into IptMsgHandler::handle_msg, to make
sure that the circuit is torn down as soon as possible on a bad
reply. (There's nothing to check yet, but there will be once we
start sending extensions that expect a reply.)
Closes #1238.
|
| |\ \
| |/
|/|
| |
| | |
Mark ShutdownStatus as must_use
See merge request tpo/core/arti!1897
|
| |/
|
|
| |
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.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
tor-hsservice: Reference #1226 instead of #1219 in a TODO.
Closes #1219
See merge request tpo/core/arti!1896
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
`note_publication_attempt` can only fail:
* due to an internal error, in which case there is no point in
retrying
* if `PublishIptSet::save` fails, i.e. if we fail to write to persistent
storage (this is #1226)
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
tor-hsservice: Add `RunningOnionService` API
Closes #1227
See merge request tpo/core/arti!1887
|
| | |
| |
| |
| |
| |
| | |
This introduces an internal `OnionServiceStateMgr` trait, which enables
us to store the `StateMgr` inside the `OnionServiceState` (without
having to parameterize `OnionServiceState` on `S: StateMgr`).
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This reduces code duplication.
|
| | |
| |
| |
| |
| | |
This code was duplicated by `create_inner()` and
`create_onion_service()`.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| | |
The functionality previously provided by the so-called `StateMgr` is now
part of `OnionService`, so we can remove state.rs altogether.
|
| | | |
|
| | |
| |
| |
| |
| | |
We are about to need the `svc_cfg` (for calling
`TorClient::create_onion_service`).
|
| | |
| |
| |
| |
| | |
This will be used from `arti` to create an `OnionService`, to implement
the `arti hss` command.
|
| | |
| |
| |
| |
| |
| |
| | |
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
|
| |\
| |
| |
| |
| |
| |
| | |
Implement is_ipt_failure better.
Closes #1234
See merge request tpo/core/arti!1889
|
| | | |
|
| | |
| |
| |
| |
| | |
Additionally, explain its behavior better, since we cannot always
identify an Ipt failure with certainty.
|
| |\ \
| | |
| | |
| | |
| | | |
shadow ci: add instructions for building arti-extra
See merge request tpo/core/arti!1891
|