| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This matches the behavior of C tor. Part of #1100.
|
| |
|
|
|
|
| |
This matches the behavior of C tor.
Part of #1100.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
(Also, correct the comments that describe them.)
We may as well match the spec names when they aren't completely
bogus.
We are already renaming these parameters for this release, so it
isn't an additional breaking change.
|
| |
|
|
|
|
| |
The old names were somewhat inaccurate. (I would have considered
keeping and deprecating the old names, but we already have breaking
changes in tor-netdir.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
```
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1904#note_2987777
|
| |
|
|
| |
Part of #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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Closes #1254.
|
| | |
|
| |
|
|
| |
This is part of #1254.
|
| |
|
|
|
|
| |
This implements Relay::is_hs_intro_point.
Close #1240.
|
| |
|
|
|
| |
As we enforce these flags in more places, it will be handy for our
default network to have them for its relays.
|
| | |
|
| | |
|
| |
|
|
| |
These are not release-blockers.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
clippy in current stable thinks
|(a, b)| (a, b)
is always the identity function, but due to match ergonomics, it might
be an implicit copy.
This is fixed in nightly by
https://github.com/rust-lang/rust-clippy/pull/11792
|
| |
|
|
|
|
| |
It does not help that C tor has a set of parameters and a set of
configuration options with exactly the same names which configure
the same thing in two slightly different ways.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The statement
```
if hsids.all(|(_hsid, period)| rings.any(|(_, _, tp)| tp == period)) {
```
had 2 bugs:
* the condition is reversed (it should be negated: we need to bail if
one of the specified `hsids` cannot be found on any of our rings)
* `rings.any()` mutates the `rings` iterator, causing
`hs_dirs_upload` to return fewer HSDirs than expected
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This threads the country codes work through the rest of the codebase:
- `tor-dirmgr` will now enable GeoIP with the embedded database when the
`geoip` future is enabled
- This can be extended later using the `DirMgrConfig` to allow
specifying a custom database; this is not done here, though
- `tor-circmgr`'s `SupportedCircUsage` and `TargetCircUsage` fields gain
new `country_code` members to allow filtering circuits by country
- These are `()` in builds where the `geoip` feature is not enabled --
doing it this way means we don't have to copy and paste huge swathes
of code, since we can't use `#[cfg]` in patterns
- `ExitPathBuilder` gains (hacked-in) support for choosing a relay with
the correct country code
- Due to the lack of conjuction, we just copy and paste a small bit,
pending further refactoring
- `StreamPrefs` now lets you specify a country code, letting embedders
make use of the feature
|
| |
|
|
| |
Apply erroneous formatting as demanded by rustfmt.
|
| | |
|
| |
|
|
|
|
|
|
| |
Call site as per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1550#note_2936401
Plus a TODO comment with an opinion from me about this API.
(Note not a TODO HSS so this is on the back burner.)
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1550#note_2936400
|
| |
|
|
|
|
| |
I'm quite unsure about this. Hence the TODOs.
I think the API is right, though.
|
| | |
|
| |
|
|
| |
`HsBlindId` is `Copy`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
When `hs_dirs` is removed this won't n't need to be public anymore.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The hsdir selection algorithm for uploads and downloads is different
enough to justify splitting `hs_dirs` into 2 different functions.
More specifically, when selecting the relays to upload a service's
descriptors to, the service's `hsids` need to be matched up with the
correct `ring` (using the time period) before applying `select_nodes` to
pick the replicas. This is not the case when downloading, because
for downloads select relays from the current ring.
|
| |
|
|
|
|
| |
These will become useful when we split `hs_dirs()` into 2 separate
functions (one for uploading/services, and another for
downloading/clients).
|
| | |
|
| |
|
|
|
| |
This just simplifies the expression a little bit. It still has the same
behaviour.
|
| | |
|
| |
|
|
| |
This will become useful later when we build a `HashSet` of `HsDirIndex`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
replicas.
This implements the part of the spec that says a node that has already
been selected for a lowered-numbered replica, shouldn't be considered
when choosing `spread` nodes for any other higher-numbered replicas.
Note: previously, the test added in this commit wouldn't have passed
(because `NetDir::hs_dirs` used to return duplicate relays under some
circumstances).
Part of #960
|
| |
|
|
|
|
|
|
|
| |
This makes `ring_items_at()` take an extra parameter which specifies
whether an item is acceptable or not. The newly added filtering
capabilities will be used to implement the part of the spec that says
that if a node was selected for a replica, then it shouldn't be
considered when choosing `spread` nodes for any other higher-numbered
replicas.
|