docs(deploy): say what happens if the report signing key is left unset - #802
Open
remyluslosius wants to merge 2 commits into
Open
docs(deploy): say what happens if the report signing key is left unset#802remyluslosius wants to merge 2 commits into
remyluslosius wants to merge 2 commits into
Conversation
Found on the v0.7.1 tag. The release was tagged while the main-branch Quality
gate was still running, and `make release-status` reported
FAIL Q1 Quality and security gates
on a job that had not finished. GitHub leaves conclusion empty for an
in-progress run, and the checker read empty as non-success.
That is the same error this tool exists to prevent: presenting the absence of
data as a fact. "The release build failed" and "the release build has not
finished" are different claims, and the first one sends someone looking for a
break that does not exist.
PENDING is now its own status. It still blocks, so nobody promotes a candidate
whose build has not finished, but it no longer accuses. Where several entries
exist for one check name, a finished result outranks a pending one, so a stale
queued entry from a re-run cannot mask a completed pass.
Two tests, and the one that matters asserts PENDING is in BAD and is not FAIL:
blocking and accusing have to stay separable.
The setting was documented as a preference: "production should set a durable key". That does not tell an operator what going without costs them. Leaving it unset does not stop the service. It mints a fresh key each boot, warns once, and signs reports normally, so nothing on any surface looks wrong. What actually happens is that every report signed before a restart stops verifying against the key the service serves afterwards, and the person who discovers that is whoever is checking the signature, not the operator who deployed it. For a report handed to an assessor, that is silent evidence invalidation found at the worst possible moment. Raised while reviewing the CMMC sprint brief, where the Document phase output goes to a C3PAO. The guide now states the consequence rather than the preference, and gives the key-generation commands with the ownership the packaged install expects, plus the warning that losing the key is the same as never setting one.
github-actions
Bot
added
documentation
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.
Raised while discharging an open item from the CMMC sprint review.
[reports].signing_key_filewas documented as a preference - "productionshould set a durable key" - which does not tell an operator what going without
costs them.
What actually happens
Leaving it unset does not stop the service. It mints a fresh key each boot,
logs one warning, and signs reports normally. Nothing on any screen looks wrong.
But the key changes on every restart, so every report signed before a restart
stops verifying against the key the service serves afterwards. The report
itself is unchanged; what changes is that its signature can no longer be
checked - and the person who discovers that is whoever is checking it, not the
operator who deployed.
For a report handed to an assessor, that is silent evidence invalidation found
at the worst possible moment. The CMMC sprint's Document phase output goes to a
C3PAO, which is what made it worth writing down properly.
Change
The guide now states the consequence rather than the preference, gives the
key-generation commands with the ownership the packaged install expects, and
warns that losing the key has the same effect as never setting one.
Docs only. No code change.