| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function returns a `TimeRangeBound`. That implies a
responsibility on the caller to check the time. It doesn't make sense
for this function to do the check as well.
But, it turns out that in tor-hsclient, the `TimeRangeBound<HsDesc>`
is sometimes processed with `.dangerously` on the assumption that it
was checked earlier. I considered changing this, and storing plain
`HsDesc` and a separate `TimeRange` - but that's not right, because
there are places where the `TimeRangeBound<HsDesc>` is used well after
it was verified.
Instead, in this commit, I (effectively) move the `.check_valid_at`
call from `parse_decrypt_validate` to its principal call site.
This involves a change to the error representation. Previously,
validity time errors ended up as `DescriptorErrorDetail::Descriptor`
containing an `HsDescError::OuterValidation` HsDescError::
InnerValidation`, which in turn contains a
`tor_netdoc::Error`. (`tor_netdoc::Error` is a rather awkward type.)
Now we have our own error variant. The overall behaviour is
unchanged.
|
| | |
|
| |
|
|
|
|
|
| |
I find these names confusing. To my mind "check" implies a function
returning `Result<(), _>`.
Some other APIs use `unwrap` here but I think `if` is good.
|
| |
|
|
|
|
|
|
|
|
| |
This just returns a tuple.
We're going to introduce a new method that returns a `TimeRagne` and
will want to be called `bounds`.
That method will want to be in the `TimeBound` trait, but for now we
add it here. Various call sites will be added in forthcoming commits.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Removed unnecessary lint
|
| |
|
|
|
| |
This saves us from having to check whether it is 0, and better
represents what the type is allowed to be.
|
| | |
|
| |
|
|
|
|
|
| |
I had incorrectly thought that this was necessary.
Fortunately, @opara looked at the spec. :)
We do, however, still need to _advertise_ negotiate_subproto.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| |
|
|
| |
"Stored" is more accurate than "current".
|
| |
|
|
|
|
|
| |
The blinded HsIds were used a proxy for the time periods, but it's
better to just compare the TPs directly.
Part of #966
|
| | |
|
| |
|
|
| |
This will soon need to be copied into `HsDescForTp`.
|
| |
|
|
|
|
| |
We no longer consider the HsDir rate-limited if its `requery == now`.
This was caught by the new tests.
|
| | |
|
| | |
|
| |
|
|
|
| |
This needs to be dropped before the next test (because the test will try
to acquire the lock inside the `Mocks` impl).
|
| | |
|
| |
|
|
|
|
| |
We need to build this twice per test (because keypairs aren't `Clone`).
I find that putting boilerplate like this in a separate function makes
the tests more legible.
|
| |
|
|
|
| |
I'm trying to reduce the cognitive load of the test a bit, because I
will soon extend it so it will grow even more complex.
|
| | |
|
| |
|
|
| |
I find very long paths a bit hard to read..
|
| |
|
|
| |
The line the comment is referring to for no longer exists.
|
| |
|
|
| |
To ensure it's actually `Ok(())` like we expect.
|
| | |
|
| | |
|
| |
|
|
| |
`connect()` no longer panics, so we don't need it anymore.
|
| | |
|
| |
|
|
|
| |
Doing this means we wont't need to go through the trouble of building a
valid `Rendezvous2` cell in the tests.
|
| |
|
|
|
| |
This is used, and is getting in the way a little bit, so I am removing
it.
|
| |
|
|
|
|
|
| |
If the blinded id has changed since we cached our descriptor, it means
the TP has changed, and so we can assume the new descriptor is fresher.
Part of #966
|
| |
|
|
|
|
| |
This enables us to tell whether a newly fetched descriptor's revision
counter can be compared with the revision counter of our cached
descriptor.
|
| |
|
|
| |
C Tor calls this a "period", but "interval" is more accurate.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
As David mentioned in a review comment, we don't want to refetch the
descriptor unless *all* introduction attempts have failed. See
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3925#note_3402810
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the client doesn't have a timely cached descriptor, then ignore
the requery period and reach out to all the HsDirs of the service.
This can, in theory, cause the client to unnecessarily query the HsDirs
when its cached descriptor has expired, but this would be a very rare
event, because the descriptor is long lived.
I'm carving out this exception to the usual rate-limiting behavior,
because I suspect having the client more eagerly reattempt the
connection will be better for UX, (by the time the client's descriptor
expires, the service, assuming it's still online, is expected to have
published a new one, so IMO it makes sense to try to fetch it).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Because we now refetch HsDirs on introduce NACK, we need some type of
rate-limiting to prevent clients from hammering the HsDirs if the
service is offline.
This rate-limiting is per-HsDir: the client will avoid querying the
same HsDir more frequently than `hs_dir_requery_period`. The HsDir
requery info is stored in the new `DataHsDirs` map.
Part of #966
|
| | |
|
| |
|
|
| |
This is no longer an `&OwnedChanTarget`, so I'm renaming it accordingly.
|