Gem Push Sigstore Bundles RFC #57
Conversation
Signed-off-by: Samuel Giddins <[email protected]>
segiddins
force-pushed
the
segiddins/gem-push-sigstore-bundles-rfc
branch
from
e08e557
to
2c88bf8
Compare
| In that case: | ||
|
|
||
| The request MUST include a part with name `gem` that contains the gem file. The `gem` part SHOULD have a `Content-Type` header of `application/octet-stream`. | ||
| The request MAY include a part with name `attestations` that contains sigstore bundles. The `sigstore` part MUST have a `Content-Type` header of `application/json` and MUST be a valid JSON array of sigstore bundle object. |
There was a problem hiding this comment.
Will you be opinionated on the contents of the bundles? Namely, should the bundle only contain attestations, or will you accept raw signatures over artifacts?
There was a problem hiding this comment.
Hmmm. Right now I have it accepting what sigstore-ruby can verify against an artifact. That includes hashedrekord entries, if that's your question
There was a problem hiding this comment.
The bundle can contain either a raw signature or a DSSE envelope. For Maven Central, they are using a signature. For npm, a DSSE envelope with a SLSA attestation. For PyPI, we defined an in-toto statement which we called an "trusted publishing attestation" which is roughly a subject and an empty predicate, and PyPI can support other in-toto statements in the future as well like SLSA attestations.
I was wondering if you wanted to define a specific format you'll accept. It'll make verification more straightforward if you accept one initial format, though I'd suggest setting it up so that you could accept other formats in the future as well, like what PyPI is doing.
There was a problem hiding this comment.
Hmm this is a good question that actually dovetails with what clients should be doing when verifying...
There was a problem hiding this comment.
I think I'm going to leave things as-is for now, and we can always restrict what attestations we allow publishing with in the future.
As-is, both raw signatures and DSSE envelopes will verify, so long as the dsse envelope is an in-toto statement with a subject that matches the artifact
| # Summary | ||
|
|
||
| RubyGems.org will add a new variant to the gem push endpoint that allows gems authors to include sigstore bundles with their gem pushes. | ||
| RubyGems.org will verify that the sigstore bundle is valid and signed by a trusted publisher configured for the gem. |
There was a problem hiding this comment.
To confirm, will trusted publishing be a requirement to accept Sigstore bundles, as in you won't accept signatures generated by a non-CI workflow identity?
There was a problem hiding this comment.
To start, I plan on limiting to trusted publishing, since it gives us a solid basis for an identity to verify against. I believe this is the approach that pypi is taking. Going forward though, I see no reason why rubygems.org fundamentally needs to restrict what attestations we accept, given they are coming from an actor that has permissions to publish to the gem
There was a problem hiding this comment.
One benefit for only accepting trusted publishing identities is if you want to provide a default verification policy, as you don't have to worry about exposing non-public maintainer details (except for dealing with private repos).
Signed-off-by: Samuel Giddins [email protected]