feat(seal): warn when the pinned anchor has been superseded - #321
Open
LKSNDRTMLKV wants to merge 8 commits into
Open
LKSNDRTMLKV wants to merge 8 commits into
LKSNDRTMLKV wants to merge 8 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the anchor-refresh half of #295. Stacked on #316; retarget as that merges.
just checkis green (1135/1135).The gap
The trust anchor is pinned from an Official Journal notice rather than chained to a certificate authority, because the LOTL's signing certificates chain to no commercial root — there is nothing to walk up to. The Commission republishes that notice.
So a pin nobody refreshes eventually meets a LOTL signed by a certificate it does not name, and fails closed as
NotAnchored— on a date nobody has in a calendar, looking like an outage rather than a lapsed pin.LotlAnchor::notice_urialready carried a doc comment saying to compare it against the LOTL's firstSchemeInformationURIentry. Nothing did. The affordance existed; the check did not.What it adds
AnchorFreshnessonVerifiedLotl—Current,Superseded { lotl_names }, orUnknown— reported and logged.A signal, never a verdict. A superseded pin keeps verifying until the certificates actually rotate, and that window is the only chance to refresh without an outage. Folding this into
LotlRejectedwould refuse documents that verify perfectly and turn the early warning into the thing it exists to prevent.a_superseded_pin_does_not_refuse_a_document_that_verifiespins exactly that.Unknownis notCurrent. A document naming no notice cannot be checked, and reporting it as up to date is how a staleness signal goes quiet at the moment it matters — the same fail-closed direction the capacity and placing-date questions take elsewhere in this workspace.Logged as well as returned, because the caller that most needs to act on it is an operator reading logs, not the code holding the
VerifiedLotl.The assumption, asserted rather than trusted
The check reads the first
SchemeInformationURIentry. That is load-bearing, so it is pinned against the real document: the LOTL lists 31 entries, and the notice is first, ahead of five pivots, the 2019 notice, the pivot explanation, and twenty-three per-language legal notices.If that ordering ever changed, the check would compare against a pivot URL and report
Supersededforever — noisy rather than silent, which is the right way round, but still wrong.the_notice_is_the_first_entry_the_document_listsfails instead.Confirmed to bite
With the comparison neutered to always return
Current, three of the five tests fail — the three asserting non-Currentoutcomes. The two positive controls correctly still pass, which is what a positive control is for.Also from #295, and not here
SealChecks::QualifiedValidationremains unreachable, deliberately. A verified list says who is qualified; it does not say a particular seal validates. That is separate work and this does not pretend to close it.What this does not solve
The refresh itself is still manual. This says the pin is stale; it does not fetch the new notice, re-read six digests out of it, or update the constant — all of which involve reading an Official Journal page, which is a human step by design. What changes is that the warning arrives while there is still time, instead of as a failed verification on an unscheduled day.