| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Our pattern is now supposed to ensure that we don't see any irrelevant
keys. So if we do, that's a bug.
(The code layout is getting increasingly odd. We'll sort that out
along with some code motion later.)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Only examine keys for this HS.
This avoids thinking about every key for every HS for every netdir
change. That's quadratic in the number of HS's.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |/ / / /
| | | |
| | | |
| | | | |
We're going to change where this is called.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
tor-hsservice: Generate revision counter using the start of SRV period.
Closes #1166
See merge request tpo/core/arti!1904
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1904#note_2987777
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Part of #1166
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These are now unused.
Part of #1166
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Closes #1166
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The publisher is the only user of `hs_dirs_upload`. It turns out it
never actually uses the first element of the yielded `Item`s, so we can
simplify `hs_dir_upload` to only return the HsDir `Relay`s.
Part of #1166
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Part of #1166
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The descriptor publisher uses this function to obtain the list of
relevant time periods. It will soon also need to know the `srv_lifespan`
associated with each time period, so we change this function to return
`HsDirParams`.
Part of #1166
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Make lower-level "hs-service" features non-experimental
See merge request tpo/core/arti!1908
|
| | | | | |
| | | | |
| | | | |
| | | | | |
It would appear nothing was using this.
|
| | | |_|/
| |/| | |
|
| |\ \ \ \
| |/ / /
|/| / /
| |/ /
| | | |
fslock-guard: sketch implementation
See merge request tpo/core/arti!1900
|
| | | |
| | |
| | |
| | |
| | | |
These are necessarily a bit hand-wavey, but I think they summarize
what we are assuming.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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`).
|
| | | |
|