| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| |
|
|
|
| |
This also adds a test, just make sure creating a `Lifetime` with
voting interval = 0 is actually impossible (and stays that way).
|
| | |
|
| |
|
|
|
| |
It's better to return a `Bug` than to panic if the consensus valid-after
is invalid.
|
| | |
|
| |
|
|
| |
This is no longer used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes Arti's SRV lifetime calculation for the case where the voting
interval != 1h, and the consensus doesn't have explicit timestamps for
the SRVs.
Credit goes to dgoulet for this fix!
See also [this thread], and #2458 for the broader context.
Closes #2522
[this thread]: https://gitlab.torproject.org/tpo/core/arti/-/work_items/2458#note_3401343
|
| | |
|
| |
|
|
| |
Run maint/add_warning
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is much code motion.
This splits many types into two. For example, `Conensus` is
now`plain::Consensus<RS>` and `md::Consensus<RS>`.
We're going to get rid of the generics later in this branch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
| |
These are new in Rust 1.83.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
```
|
| |
|
|
| |
Part of #1166
|
| | |
|
| |
|
|
| |
This is part of #1254.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
(Adding comments explaining that these errors are really
unlikely to occur, unless there is a bug in our code or in Rust's
time handling.)
|
| | |
|
| |
|
|
|
| |
I was going to add a comment about "doing this if we need the voting
period anywhere else" but it turns out that we also use it in dirmgr.
|
| |
|
|
|
|
| |
* Return a more informative error type (instead of Option)
* Check that time periods are an integer number of seconds
* Decide not to change the semantics of an argument.
|
| |
|
|
| |
Fixes #756
|
| | |
|
| |
|
|
|
| |
This already allows us to get rid of some duplication, and will be
useful more widely in a moment.
|
| | |
|
| |
|
|
| |
This will allow us to tell if we can reuse parts of a ring.
|
| |
|
|
|
|
|
|
|
| |
The file which contains this type is called hsdir_params.rs. We have
a general problem with slight confusion about when to includen "dir"
and when to include "ring".
Resolve this in favour of the rule now added to the module-level doc
comment.
|
| |
|
|
|
|
|
|
|
|
| |
These variables are going to be struct fields, which will sort of
enforce consistent naming. The struct fields are going to appear in a
moment. We'll call the fields "current" and "secondary" after the
naming in the test cases.
And import hsdir_params::HsRingParams, which we're going to make more
references to.
|
| |
|
|
|
|
| |
This will enable us to pass these around more conveniently.
And make empty_from_params take an owned params, which it would like.
|
| |
|
|
|
|
| |
Locally, the only functional effect is that now we refuse to handle
non-whole-number-of-minutes lengths - but since the consensus
parameter can't represent those, there's no overall functional change.
|
| | |
|
| |
|
|
|
| |
It's cute, but I don't think it will help performance, and I'm
undecided about whether the semantic implications are true.
|
| | |
|
| | |
|
|
|
This logic is a bit tricky, so I've tried to document it and add
fairly good tests. The silver lining is that the external API for
all of this logic will make it invisible and hidden.
There are some cases where I added functions that I think might
eventually get lowered into MdConsensus: But I don't want to lower
too much right now, since the convention for our netdoc accessors is
that they are fairly unsophisticated, and they show you the document
as it is.
Closes #686
|