Repository navigation
A production release's acceptance holds, and its flow is rehearsed in CI - #157
Merged
Merged
Conversation
…tl key the medium's anchor lists signed its file, in that key's own namespace: a third key beside the release and statement keys, made by the ceremony and by the build for the suites, kept with the production pair; mk-testctl.sh signs, testctl.sh verifies against the medium's anchor and names a disk it ignores, and the install suite boots one signed by a stranger
…lease's media honour (KRYPTIK_TESTCTL_KEY passes through sudo like the rest of the contract), the instructions name it, and the medium's check, the suites' default key and the pair's copy are written once
… CI: the boot tests enrol the Secure Boot certificate the medium under test carries and the export publishes that certificate, not the developer key's; a production version's run (a tag from v1.0.0, or the role asked for) builds and tests the revision signed with a throwaway key medium and drafts nothing from it; the instructions build the pair and a 0.0.0 release before the release, and test before tagging
…trust, of either role: what the guest refuses is the signer, and a production release under test has only production builds to hand it
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.
The release flow in docs/release-keys.md (a production build by hand, then
make acceptance, then the tag and the page) had never been run, and it would not have passed:<work>/keys/sb/kryptik-sb.crt), which does not exist in a fresh production tree and is not what signed a production release's kernels, somedia-smoke-securebootandintegrity-testwould fail; the export published that developer certificate as the release's. Nowacceptance.shreads the certificate out of the medium under test (/kryptik/kryptik-sb.crton its ESP), enrols that one, and the export carries it in PEM and DER form. The integrity suite checks its controls against the same certificate.v1.0.0up would have built a developer-signed 1.0.0 and drafted it on the Releases page as a pre-release, so the hand-built release could not be published under the same tag. Now such a tag's run builds and tests the revision as a production release signed with a throwaway key medium, the same commands the instructions give, and drafts nothing; only av0.xtag is drafted. Aworkflow_dispatchinputrole=productionrehearses that flow on any ref.0.0.0, then the release, test, tag and publish, in that order.Stacked on signed-testctl (#155): it carries that branch's commits until #155 merges. Its Distro run is dispatched with
role=production.