Add migration material #1257
Add migration material #1257
Conversation
This script sets up the tuf-on-ci repository so that the initial signing event can be run. Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
These are likely not complete (e.g. key generation is under-documented). Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
import-config.json is used as argument to tuf-on-ci-import-repo, it includes: * offline role expiry and signing periods to set in metadata * keyowners or online signing key identifiers for existing keys * snapshot key is left with placeholder value: it (along with online expiry and signing periods) is expected to be modified with a tuf-on-ci-delegate call in the same signing event Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
| Every signer in the repository needs to sign the signing event at this point by running `tuf-on-ci-sign`: | ||
| this is required because the keyids of all keys have changed (the actual key content has not). | ||
|
|
||
| ** TODO: This includes the npmjs signer: it is unclear how this signing happens at this point** |
There was a problem hiding this comment.
@kommendorkapten for your thoughts
There was a problem hiding this comment.
I'm currently working on figuring out the details here, I'm hoping to have an issue with the overall ideas for how external (kms) signing can be added to tuf-on-ci for delegations.
|
Marking ready for review: I think this needs some other pair of eyeballs, mine are not useful here anymore |
|
I too can be biased here, but I think the documentation is good. |
|
|
||
| #### General outreach | ||
|
|
||
| Communicate the upcoming changes to Sigstore community |
There was a problem hiding this comment.
How? How much notice will you give? I know root-signing changes have been difficult to communicate in the past with typically one or more folks feeling they hadn't had notice. cc @haydentherapper
There was a problem hiding this comment.
This is a fair concern. I think the prep work has been done this time:
- staging should now be a fairly solid example of what's going to happen
- clients are being tested with staging (and will be with prod)
- the one expected failure (sigstore-rs) has been communicated to that project
What we can do now is
- make the timeline clear: as soon as we know the estimated date, publish it (it's currently looking like we can't manage this before august because of still missing npmjs signer support)
- keep the clients slack channel informed during the process
I'll take additional suggestions.
There was a problem hiding this comment.
Are all the client implementations we care about actively monitoring the #clients channel? If not, we might be proactive and keep the maintainers in the loop via email (perhaps at their request)?
There was a problem hiding this comment.
Going forward, we hopefully won't have breaking changes so clients won't need to follow along.
As for getting the keyholders ready, just need to make sure we schedule regular signings with a few weeks notice. Might be worth revisiting the set of keyholders as well and make sure everyone is still onboard with being available with minimal notice in the event of needing an immediate rotation.
Signed-off-by: Jussi Kukkonen <jkukkonen@google.com>
|
|
||
| #### General outreach | ||
|
|
||
| Communicate the upcoming changes to Sigstore community |
There was a problem hiding this comment.
Going forward, we hopefully won't have breaking changes so clients won't need to follow along.
As for getting the keyholders ready, just need to make sure we schedule regular signings with a few weeks notice. Might be worth revisiting the set of keyholders as well and make sure everyone is still onboard with being available with minimal notice in the event of needing an immediate rotation.
Add documentation and one time scripts for tuf-on-ci migration (#1247, see #929 for more context).