Warn (and optionally fail) on a stale trust root with --offline - #1872
Open
mangrisano wants to merge 1 commit into
Open
Warn (and optionally fail) on a stale trust root with --offline#1872mangrisano wants to merge 1 commit into
mangrisano wants to merge 1 commit into
Conversation
Adds staleness checks in offline mode based on the cached TUF timestamp metadata expiry, configurable via --offline-staleness-warn / --offline-staleness-error (and the SIGSTORE_OFFLINE_STALENESS_* environment variables). Closes sigstore#1175 Signed-off-by: Michele Angrisano <michele.angrisano@gmail.com>
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
1 participant
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 #1175.
Summary
--offlinedisables TUF trust root refresh, so a user can end up verifying against a very stale trust root without realizing it (missing key rotations or revocations). This adds a staleness check in offline mode.Behavior
When verifying with
--offline,TrustUpdaterinspects the cached TUFtimestamp.jsonmetadata and compares itsexpiresagainst the current time:TUFError, aborting verification.If there is no cached
timestamp.json(e.g. a fresh install running only off the embedded trust root, never refreshed), the check is skipped (debug log only).Why "past expiry"?
The TUF
timestamprole'sexpiresis the only signed temporal anchor available offline (there is no signed "issued at"), and it's exactly TUF's mechanism for bounding freshness. So staleness is measured asnow - timestamp.expires: the thresholds mean "expired for longer than X", i.e. a grace period on top of the repository's own declared expiry.Configuration
Both thresholds are configurable, and either can be disabled with
off(or0):--offline-staleness-warn/--offline-staleness-error(durations like24h,7d,2w)SIGSTORE_OFFLINE_STALENESS_WARN/SIGSTORE_OFFLINE_STALENESS_ERRORThey thread through
ClientTrustConfig.from_tuf/production/stagingdown toTrustUpdater, so library users get the same defaults (and can customize viaClientTrustConfig).Notes / open questions
--offlineshould warn when the trust root is unreasonably old #1175 — happy to tune.Verifier.production/staginguntouched: the defaults already flow through them, so per-threshold customization there felt like speculative API surface. Glad to add it if you'd prefer.Tests
Added unit tests in
test/unit/internal/test_trust.py: warn, hard error, fresh (no warning), missing timestamp (quiet), and error-level disabled.