docs: add orchestration playbook and fix rotation #292
Conversation
Signed-off-by: Asra Ali <[email protected]>
|
|
||
| 2. Make updates to the targets and delegation configuration files, see [configuration](#targets-and-delegation-configuration). | ||
|
|
||
| 3. Double-check the configured [role expirations](https://github.com/sigstore/root-signing/blob/e3f1fe5e487984f525afc81ac77fa5ce39737d0f/cmd/tuf/app/init.go#L28). |
There was a problem hiding this comment.
Not for docs, but can this be a part of a pre-verification step somewhere in the scripts?
There was a problem hiding this comment.
Adding this here to track for v5: #98
But I might be misunderstanding what you mean.
There was a problem hiding this comment.
Yea, I was thinking that a verification script can check for these exact expirations.
playbooks/ORCHESTRATION.md
Outdated
| | GITHUB_USER | The GitHub user, used to create PRs and commit messages | asraa | | ||
| | BRANCH | The working branch, in case of staging script or configuration changes. | main | | ||
| | LOCAL | If enabled, keeps git state dirty and does not create pull requests. Used to run root signing locally for testing. | | | ||
| | REPO | Specifies the repository folder, see [Configuration](#configuration) | `ceremony/2022-02-22` | |
There was a problem hiding this comment.
Should you also mention needing to set this if you're doing the signing across multiple days, since the date changes?
There was a problem hiding this comment.
These are all variables that need to be set unless indicated, so I think that's clear? I did add that by default it chooses the current date.
This might not even be a ceremony/date repo -- could also be repository/repository.
| └── revocation.json | ||
| ``` | ||
|
|
||
| Manually check for: |
There was a problem hiding this comment.
I think a verification script for this step, where we just hardcode expirations and check for things like version+1-from-previous would be helpful.
There was a problem hiding this comment.
I need a human eyeball to check for this at some point though...
Or else I can compare against the expiration map, but that's where the info was populated from.
I guess the verifier is somewhat of a code boundary -- unless the orchestrator/verifier filled out their expectations I don't think I can automate this easily. File an issue if you have a clear vision?
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali [email protected]
Summary
Ticket Link
Fixes #261
Release Note