slsa-framework / slsa-github-generator

Language-agnostic SLSA provenance generation for Github Actions
Apache License 2.0
430 stars 129 forks source link

[feature] Rename private-repository input #1428

Open s-spindler opened 1 year ago

s-spindler commented 1 year ago

Is your feature request related to a problem? Please describe. The private-repository input is unfortunately named, especially considering that it is a boolean flag. private-repository: true makes me think "Yep, I'm using this in a private repository, better set it."

Describe the solution you'd like Rename the input to something less confusing, whatever that may be. push-to-public-rekor maybe?

Describe alternatives you've considered The private-repository could be replaced by a dict option as part of making rekor configurable (#372):

rekor-configuration:
  use-public-rekor: false
  rekor-url: https://rekor.blabla.com

Additional context

asraa commented 1 year ago

The private-repository could be replaced by a dict option as part of making rekor configurable (https://github.com/slsa-framework/slsa-github-generator/issues/372):

Big +1 ! We should be doing configurable sigstore instances this quarter, and moving smoothly to a dictionary option would be the best. I would propose something like

sigstore-configuration:
   instance: (staging, pre-production, public [default]) // One of pre-set configured instances
   custom-root: my-custom-tuf-root
   custom-mirror: my-custom-tuf-mirror // TUF repository contains the URLS for the services
   push-to-public: true // If using the public instance, allow private repo push. must be explicitly set for private repos

Either instance of custom-root/custom-mirror are specified.

This forces users to use a whole sigstore TUF instance. so if they want to push to a private repository, they must have a private TUF repository distributing the key material (https://blog.sigstore.dev/sigstore-bring-your-own-stuf-with-tuf-40febfd2badd). It doesn't suffice to just specify the service URLs, you also should validate the signatures they send back with trusted key material. If we didn't want to go that route, we'd need a way to specify the service URLs AND their keys:

sigstore-configuration:
   instance: (staging, pre-production, public [default]) // One of pre-set configured instances
   custom-rekor-url: my-custom-rekor
   custom-rekor-key: custom-rekor-pubkey
   custom-fulcio-url: my-custom-fulcio
   custom-fulcio-ca: custom-fulcio-root
   custom-ctfe-url: my custom-ct
   custom-ctfe-key: custom-ct-key
   push-to-public: true // If using the public instance, allow private repo push. must be explicitly set for private repos

That seems a lot messier. :| A TrustRoot protobuf is being defined in https://github.com/sigstore-protobuf-specs, so we could also use something like a serialized protobuf holding this info, similar to the TUF configuration:

sigstore-configuration:
   instance: (staging, pre-production, public [default]) // One of pre-set configured instances
   custom-trust-root: my-custom-trust-root // Contains service URIs and trusted key material
   push-to-public: true // If using the public instance, allow private repo push. must be explicitly set for private repos

Overall, I think it's better to start with the sigstore-configuration with an instance to toggle hard-coded staging, pre-prod, and prod environments. Then add in the custom-(trust/tuf)-root, so long as we document how one can create a custom trust root with custom service URIs.

ianlewis commented 1 year ago

For reference, the suggested flag for allowing recording on the public ledger for npm is --force-public-provenance.

https://github.com/npm/rfcs/blob/main/accepted/0049-link-packages-to-source-and-build.md#what-goes-on-the-public-rekor-ledger