Repository navigation
guardrail: take the emission date out of the canon digest - #7
Merged
Merged
Conversation
compute_canon_id no longer hashes the payload's `Emitted <date>` line, so the canon id tracks the vocabulary instead of the calendar. Re-emitting with no vocabulary change used to move the id, which made every vendored copy read as out of date and turned the daily fan-out into one pull request per repo changing a single date. Vendored from the canon repo: canon_payload.py and check.py only. profile.py is hand-written per repo and is untouched. Canonical id aa4301c6f0fd; this public copy carries the redacted variant ff28e99a952b with an empty DEFINITIONS list.
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.
Vendored guardrail sync. Two travelling files changed:
tools/product_guardrail/canon_payload.pyandtools/product_guardrail/check.py.What moved
compute_canon_idnow excludes the payload'sEmitted <date>.line from the digest, alongside theCANON_IDline it already excluded.Why
The emitter stamps today's date into the payload, and that line was being hashed, so the canon id was a function of the calendar rather than of the vocabulary. Re-emitting with no vocabulary change at all still moved the id; every vendored copy then read as out of date, and the daily fan-out asked for one pull request per product repo whose entire content was a changed date. The id now answers only "is this the same vocabulary", which is the question anyone actually asks it.
The exclusion is anchored to a bare ISO date (
^Emitted \d{4}-\d{2}-\d{2}\.$), not to^Emitted, so the excluded line cannot be used to smuggle unhashed text past the digest. The self-test asserts it in both directions: the emission date must not move the id, and any other line must.Verified in this checkout, before the commit
python3 tools/product_guardrail/check.py --self-testexits 0:product-guardrail self-test passed: 15 entries both ways, 8 extractor specimenspython3 tools/product_guardrail/check.pyexits 0:CANON_IDin the synced payload isff28e99a952b791210cf743af8eecb3117f5cdd51f0f92710061b72dd8ff0330, the redacted public variant of canonicalaa4301c6f0fd….len(DEFINITIONS) == 0, as it must be in a public copy: the maturity ledger is redacted from public payloads.profile.py is untouched
git status --porcelainafter the write showed exactly the two files above.profile.pyis hand-written per repo (what to scan, what to skip, the grace list) and never travels; this sync did not read from it or write to it.Exit codes above were captured without a pipe, so they are the real exit codes of the commands themselves.