Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] Rename private-repository input #1428

Open
s-spindler opened this issue Dec 30, 2022 · 2 comments
Open

[feature] Rename private-repository input #1428

s-spindler opened this issue Dec 30, 2022 · 2 comments
Labels
area:container Issue with the generic container generator area:generic Issue with the generic generator area:go Issue related to the Go ecosystem type:feature New feature or request

Comments

@s-spindler
Copy link

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

@s-spindler s-spindler added status:triage Issue that has not been triaged type:feature New feature or request labels Dec 30, 2022
@ianlewis ianlewis added area:go Issue related to the Go ecosystem area:generic Issue with the generic generator area:container Issue with the generic container generator and removed status:triage Issue that has not been triaged labels Jan 4, 2023
@asraa
Copy link
Collaborator

asraa commented Jan 5, 2023

The private-repository could be replaced by a dict option as part of making rekor configurable (#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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:container Issue with the generic container generator area:generic Issue with the generic generator area:go Issue related to the Go ecosystem type:feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants