mirrors/arti.git/crates/tor-netdoc/src/doc/hsdesc.rs, branch arti-v2.5.1

tor-netdoc: HsDesc parse_decrypt_validate: Fix docs re time bounds

2026-07-23T10:13:55Z

As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4223#note_3438348

HsDesc::parse_decrypt_validate: Don't check validity time (style followup)

2026-07-23T10:13:55Z

HsDesc::parse_decrypt_validate: Don't check validity time

2026-07-23T10:13:54Z

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` 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` 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.

tor-netdoc: hsdesc: Use new TimeRangeBound::build_intersect (fmt)

2026-07-23T10:13:34Z

tor-netdoc: hsdesc: Use new TimeRangeBound::build_intersect

2026-07-23T10:13:34Z

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.

tor-netdoc: hsdesc: Rename a variable

2026-07-23T10:13:34Z

This variable had a different name inside the block, to outside. This was confusing, and, fixing it makes the next commit clearer.

tor-checkable: Rename `TimeBound::is_valid_at` to `check_valid_at`

2026-07-23T10:13:34Z

I find this names confusing. To my mind "is" implies a function returning `bool`.

tor-checkable: Rename `TimeBound::check_valid_` to `if_valid_`

2026-07-23T10:13:34Z

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.

Use new TimeRangeBound name throughout the tree

2026-07-16T15:47:50Z

Use new TimeBound name throughout the tree

2026-07-16T15:47:50Z

mirrors/arti.git/crates/tor-netdoc/src/doc/hsdesc.rs, branch arti-v2.5.1

tor-netdoc: HsDesc parse_decrypt_validate: Fix docs re time bounds

HsDesc::parse_decrypt_validate: Don't check validity time (style followup)

HsDesc::parse_decrypt_validate: Don't check validity time

tor-netdoc: hsdesc: Use new TimeRangeBound::build_intersect (fmt)

tor-netdoc: hsdesc: Use new TimeRangeBound::build_intersect

tor-netdoc: hsdesc: Rename a variable

tor-checkable: Rename `TimeBound::is_valid_at` to `check_valid_at`

tor-checkable: Rename `TimeBound::check_valid_*` to `if_valid_*`

Use new TimeRangeBound name throughout the tree

Use new TimeBound name throughout the tree

tor-checkable: Rename `TimeBound::check_valid_` to `if_valid_`