update Sigstore community roadmap #315
Conversation
Signed-off-by: Bob Callaway <bcallaway@google.com>
|
The time stamp server seems missing in this document. |
|
@oej, under the transparency log roadmap, we mention "Timestamp at Entry Upload", so that TSA timestamps are included in the log and become immutable, and "Roughtime for distributed trusted timestamps", which is a long-term vision for distributed trusted timestamping. The timestamp server at https://github.com/sigstore/timestamp-authority is feature complete at this point. Was there anything you thought we needed to call out? |
|
@haydentherapper I just noted that it was missing and wondered if it was a mistake. Obviously not. Maybe add a comment that the time stamp server is feature complete if others wonder too :-) Thank you for the feedback! |
|
|
||
| ### Short Term (< 6 mo) | ||
|
|
||
| * Releases: |
There was a problem hiding this comment.
anything for sigstore-js here?
There was a problem hiding this comment.
@bdehamer Anything you wanted to call out? Any major releases in the next year?
There was a problem hiding this comment.
No major releases planned. I've got a long list of small features/improvements I'll be working on but nothing worth calling-out here.
|
|
||
| * ACME for code-signing certificates (ongoing RFC) | ||
| * Native SPIFFE support with X509-SVIDs as authenticators, rather than supporting only OIDC | ||
| * Support revocation for private deployments |
There was a problem hiding this comment.
is revocation for the public deployment intentionally omitted? This could be useful for key or account compromise (discussed in #sigstore/cosign#677)
There was a problem hiding this comment.
It's a hard problem on a large scale - How do we authenticate requests to revoke content? How do we maintain an indefinitely growing list? WebPKI doesn't deal with revocation well, and I worry we'd run into the same issues.
There was a problem hiding this comment.
I agree that this is challenging, and should be part of the 12 months+ roadmap. But if Rekor is used to discover a mis-behaving key/identity, Sigstore should do something about this. Whether this is a revocation list, TUF delegations to trusted identities, or some other mechanism.
There was a problem hiding this comment.
Is this revoking specific entries in the log by UUID, revoking everything signed with public key X, revoking everything signed by x509 cert with serial Y, or revoking everything signed by foo@bar.com between a date range?
There was a problem hiding this comment.
I'd like to see ecosystems making decisions on how to handle revocation, possibly along with per-ecosystem log deployments, rather than the central log. Possibly one thing we could explore is delegated or namespaced revocation lists.
@jalseth, all of those imo. The flexibility is why I think this should be handled by consumers and ecosystems rather than by a central log.
There was a problem hiding this comment.
I think that fits under the client roadmap with "Policy: sophisticated verification policies, or deeper integration with a policy evaluation service".
There was a problem hiding this comment.
I suggest we don't use the word "revocation" until we had a discussion about it. Avoiding any "revocation" solution is generally a good thing, since most of them has not worked very well. So Hayden's suggestion seems good.
There was a problem hiding this comment.
Right, that makes sense: each, say, package registry may wish to handle revocation separately from Sigstore. Sigstore should ideally "just" be a (but not the only) source of truth.
There was a problem hiding this comment.
Do we have a resolution about this? @mnm678 @haydentherapper
There was a problem hiding this comment.
Hayden's interpretation of it fitting under the policy item works for me
| * New releases should go to staging automatically | ||
| * Releases should seamlessly move from staging to production with automated testing | ||
| * New bleeding-edge environment | ||
| * Hourly/nightly releases should automatically deploy to this env |
There was a problem hiding this comment.
Should there be a point here about monitoring metrics and filing issues (preferably automatically) for errors in this env?
There was a problem hiding this comment.
That's a good callout, we have an issue in the private infra repo for tracking automatically filing issues on GH, but this has not been completed.
|
|
||
| ### Long Term (12+ mo) | ||
|
|
||
| * Public root of trust trusted by private ecosystems (Apple App Store, Google Play Store, Windows) |
There was a problem hiding this comment.
I assume this includes some collaboration on a default policy for each (operating on some sort of SBOM), as trusting any plain Sigstore signature would be risky. If my assumption is correct, should that be called out here?
There was a problem hiding this comment.
Policy would need to be a part of this, yes.
| Sigstore is inherently flexible and can natively support a variety of: | ||
|
|
||
| * deployment scenarios (e.g. public-facing VS private enterprise deployments), | ||
| * key management approaches (e.g. hardware-backed keys stored in HSMs or Yubikeys or ephemeral scenarios where a private key can be deleted immediately after use), |
There was a problem hiding this comment.
nit: Ephemeral keys should not be persisted to disk, so no delete operation needed. This doc may be the first time a user encounters the idea of ephemeral keys, so I think this is worth clarifying.
There was a problem hiding this comment.
Deleted could also be cleared from memory.
|
Discussed in SIG-clients meeting today. Overall looks good to us + compatible with our roadmap, we'll leave specific comments as warranted. |
|
|
||
| ### Short Term (< 6 mo) | ||
|
|
||
| * Add 2 independent log monitors |
There was a problem hiding this comment.
Should we call out what we want to use to monitor the logs? I know we have a monitoring project here in the Sigstore org that I believe powers the Purdue monitor. Should there be a roadmap for that kind of functionality?
There was a problem hiding this comment.
Good suggestion, I’ll add a section on that. I have a roadmap for what’s needed to enable witnessing and identity monitoring.
There was a problem hiding this comment.
Added roadmap, PTAL!
Co-authored-by: Hayden B <hblauzvern@google.com> Signed-off-by: Bob Callaway <bobcallaway@users.noreply.github.com>
Co-authored-by: Zach Steindler <steiza@github.com> Signed-off-by: Bob Callaway <bobcallaway@users.noreply.github.com>
|
Thanks to everyone for their feedback - again the intent is for this to be a living document, so please feel free to submit a PR to update this at anytime. |
Hi everyone!
The @sigstore/core-team has been working on updating the community's roadmap through conversations with our maintainers, users, and others in the wider OSS ecosystem. Our draft is now at a point where we'd like to solicit broader community feedback.
We are targeting to merge this by September 15th, 2023; however, our intent is that this is a living document, so PRs are always welcome :)