| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The publisher status is obtained via `StatusSender` (rather than by
polling `Publisher::status()`).
Part of #1083
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This isn't something we need to do for #1083.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The new names are shorter and just as descriptive.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We need it to be public, because we're about to expose it in the
`OnionServiceStatus`.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We're about to report the inner error in the `OnionServiceStatus`
(without making `BackoffError` public).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
They're not used anywhere, so let's remove them.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The key expiration status is only relevant if the service is running in
"offline mode", so these TODOs should be part of #1194.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This field is unused now that we have `ipt_mgr_state` and `publisher_state`.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Part of #1083
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The publisher needs it to notify `OnionService` of status changes.
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | | |
For updating the underlying component statuses of an `OnionServiceStatus.
Part of #1083
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | | |
tor-hsservice: Make offset_within_srv_period() work with timestamps from newer periods.
See merge request tpo/core/arti!1914
|
| | | | | | |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
newer periods.
This fixes a bug where `offset_within_srv_period()` returns `None`,
instead of the offset of `when` from the start of the SRV of the
previous time period:
```
2024-01-24T15:24:46Z ERROR tor_hsservice::svc::publish::reactor: descriptor upload failed for HS service
allium-cepa2 and time period TimePeriod { interval_num: 19745, length: IntegerMinutes { value: 1440 },
epoch_offset_in_sec: 43200 }: error: Programming error: internal error (bug) at
/../arti/crates/tor-hsservice/src/svc/publish/reactor.rs:218:13: current wallclock time not within
SRV range?! (now=SystemTime { tv_sec: 1706109886, tv_nsec: 246572852 },
SRV_start=SystemTime { tv_sec: 1705968000, tv_nsec: 0 })
```
We need to be able to calculate this offset even if `now` is not within
the SRV range (because we upload the descriptor to the HsDirs of the
*previous* time period too).
Note a similar bug exited in `offset_within_period()` (which no longer
exists) too! That one was fixed in !1744:
```
Hidden services can have multiple "active" time periods for which they
generate descriptors. We need to be able to compute the offset of a
timestamp from the start of a given time period, even if that timestamp
falls within the "next" time period (for example, when publishing
descriptors for the "previous" time period, the `when` timestamp will
fall outside the `(start, end)` range of the "previous" time period).
```
|
| |\ \ \ \
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | | |
hsservice: Fix some errorkinds and related error handling issues.
Closes #1225
See merge request tpo/core/arti!1906
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Also, change `keep_intro_established`'s return type to indicate that
it has no non-failing return cases.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We already have the NetDir in establish_intro_once, so we might as
well use it to get the intro-point details there.
This confirms that we will not need IptError::NoNetdir, since we
use wait_for_netdir in establish_intro_once.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This is not typically wrong, but it may become wrong if we do not
tidy up MissingHsIdKeypair in the future. The TODO now refers to
|
| | | | |
| | | |
| | | |
| | | | |
This is now #1255, which is not a MUST.
|
| | | | |
| | | |
| | | |
| | | | |
Part of #1225, also #1237.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We use this for a RetryError in circmgr, but we will also want it in
hsservice.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | | |
fslock-guard: use winapi to test file-equivalency on windows
Closes #1258
See merge request tpo/core/arti!1910
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Do TP-based HSS key expiry in publisher reactor.
See merge request tpo/core/arti!1909
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Now the remove_if_expire closure, which does the actual work, is
lexically outside the macro, and the macro is trivial.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This allows us to have a closure containing runtime-polymorphic code,
reducing monomorphisation and moving code out of a macro into a
closure.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| | | | | | |
|