| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4225#note_3438787
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4225#note_3438786
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Although we have other places in-tree where we do this very standard
thing, we don't seem to have an affordance for it. I doubt we want to
add a dependency just for this, so roll our own.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This just panics, right now.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-dirmgr: Refactor function download
See merge request tpo/core/arti!4204
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Add helper functions: perform_download, advance_state, apply_state, and
update_state
- Add enum used in said helper functions: DownloadOutcome and AdvanceStateError
- Add minor improvements on the readability of the entire sub-module
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
hashx: Update dynasmrt to 5.1.0
Closes #2637
See merge request tpo/core/arti!4232
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This was forgotten in the previous commit.
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes a rust future-incompatibilities warning, which was caused by
the proc-macro-error2 crate.
The dynasmrt crate switched to a fork proc-macro-error3 to fix this.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
tor-cert-x509: Fix RSA key size check
Closes #2626
See merge request tpo/core/arti!4231
|
| | | | | | |
|
| | |/ / / |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4223#note_3438348
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4223#note_3438344
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4223#note_3438341
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Replace open-coding of various is_valid_at and various dangerously and
intersect. In more detail:
* Do most of the processing inside `TimeRangeBound::build_intersect`
* Replace uses of dangerously_peek etc. with `TimeBound::unwrap_with`
* The timebound machinery now takes care of doing the intersection
* Remove the individual `.is_valid_at` calls and replace them with
one at the end, on the intersection. This preserves the current
behaviour except that sometimes time validity errors will now be
reported as having occurred the wrong level. We'll deal with this
in a moment (by deleting these checks from here entirely).
* There is no need to handle a `None` from `intersect` any more.
TimeBound handles conflicting time ranges differently: it
allows ranges which are empty due to being ill-formed.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This variable had a different name inside the block, to outside. This
was confusing, and, fixing it makes the next commit clearer.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I find this names confusing. To my mind "is" implies a function
returning `bool`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
It wouldn't make much sense for one concrete type to be unwrappable
variously as different inner types.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
It is better to return a more cooked type. `TimeRange` aka
`TimeRangeBound<()>` is perfect for this.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now that we have `bounds()`, we can centralise this implementation and
delete the implementations.
I don't think it's necessary to provide an engineered safeguard
against downstreams overriding this method. Any existing implementors
of this trait will break because they must provide `.bounds()` now,
which is an opportunity to notice that the `is_valid_at` can be
deleted. But, if it is not deleted, nothing goes wrong.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This was always TimeValidityError. And we want to rely on that so we
can do the validity checking more centrally.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This makes a `TimeBound` much more convenient to work with, will allow
more centralisation.
This replaces temporary `bound` inherent method on `TimeRangeBound`.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This is our time range type, so it wants a bunch of useful methods and
conversions.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It was confusing that one of these functions had "which bound"
mentioned in its name, but the other didn't. So add `end` and switch
from `tolerance` to `bound` (see previous commit message).
*This* commit should deal only in `extend_tolerance` and `end` and
shouldn't touch `extend_start_bound` or `extend_pre_tolerance`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Although it is often used to apply a tolerance, it doesn't make sense
to say that this is extending the "tolerance" of a `TimeRangeBound`.
A `TimeRangeBound` doesn't have a tolerance, only bounds.
Also we should be consistent in our terminology, and use `start`
rather than `pre`.
We'll rename the other method too. Doing them one at a time will
makes it easier to spot any "pre/start" vs "<nothing>/end" slips:
*this* commit should deal only in `pre` and `start` and shouldn't
touch `extend_tolerance`.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This puts the start bounds extension function before the end one.
That makes sense because starts are before ends.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | | |
I find this hard to read without them.
|
