root-signing icon indicating copy to clipboard operation
root-signing copied to clipboard

[root v11] signing period length

Open jku opened this issue 1 year ago • 3 comments

Current situation:

  • root signing period is 31 days: so the signing event PR opens 31 days before expiry
  • tests file an issue if root is not valid 30 days into the future

This is not completely sustainable as it means signing events must finish within in a day, otherwise tests start complaining. There seem to be two main options:

  • extend signing period (possibly also extend expiry period if signing frequency should remain the same)
  • lower the expected root validity time to e.g. 15 days

CC @sigstore/tuf-root-signing-codeowners and @sigstore/sigstore-keyholders for opinions, I'm not sure what I'd like to do here.

jku avatar Sep 03 '24 10:09 jku

I would vote for extending both the root validity and the signing period, with eg. 15 days to give us enough time to perform the signing. By extending both the signing period and the validity we would still get the same starting date as with the current configuration, without risking any prober alerts.

kommendorkapten avatar Sep 03 '24 11:09 kommendorkapten

I agree to extending both. I think we should try to leave 2 weeks to handle any issues, so I would say 21 days for the root signing period and 14 days for the issue, giving signers a week.

haydentherapper avatar Sep 03 '24 16:09 haydentherapper

I agree to extending both. I think we should try to leave 2 weeks to handle any issues, so I would say 21 days for the root signing period and 14 days for the issue, giving signers a week.

There are three deadlines we need to juggle and I can't quite parse that fully, so I'll write this out to make sure we all agree.

  • PR is first opened signing-period days before expiry date. Currently this is 31 days.
  • first deadline is in this project: An issue is filed in root-signing X days before expiry (currently X==30). This should be long enough that we can still organize a signing event without pain if somehow nothing had happened before this.
  • second deadline is oncall: Alert happens Y days before expiry (currently Y==15)

Fredrik suggested extending signing period (and expiry) by 15 days and that feels reasonable, then we would have

  • PR is opened 45 days before expiry
  • issue is filed in root-signing 30 days before expiry
  • oncall is alerted 15 days before expiry

With these deadlines some scenarios would look like:

  • When everything works this leaves 1 week for maintainers to build the signing event and 1 week for signers to sign before an issue gets filed
  • If signing event creation for some reason fails that still leaves the same deadlines (1+1 week) before on-call is alerted
  • if root-signing completely dropped the ball and on-call has to interve, that still leaves the same deadlines (1+1 week) before clients start failing

jku avatar Sep 10 '24 14:09 jku