search

github-early-access / generate-build-provenance

Publish a signed build provenance from your GitHub Actions workflow
MIT License
63 stars 30 forks source link

Feature: A way to run the Action as a local service #101

Open laurentsimon opened 9 months ago

laurentsimon commented 9 months ago

Package managers (e.g., npm) need to implement sigstore client library to enable provenance for their users. If we could turn the GHA in this repo into a deamon (that users could can add as a step), it would lower the barrier to entry. Package managers could send a REST API to a local address and get the provenance in the response.

Maybe there's another way to do it, but above is the first that comes to mind

trevrosen commented 9 months ago

TBH I'm not 100% what you're asking for here - do you mind clarifying? The Action writes provenance, and GH CLI verifies it. I don't follow turn the GHA in this repo into a daemon (that users could add as a step)

The new gh-attestation CLI extension / command ships the trust root for both GitHub and Sigstore PGI Fulcio instances, so anything constructed on GitHub can be subsequently verified in a fairly high-trust way b/cgh is a static binary. You could imagine package managers potentially shipping this binary to client machines in the future.

To my way of thinking, the larger barrier to entry for registry adoption is getting registries to produce a publish attestation (the way that npm does today) in order to bind the published artifact to the build job that produced it.

laurentsimon commented 9 months ago

Let me clarify. As a package manager CLI, if you want to support provenance and send it to the registry at publication time, you have 2 options:

  1. Implement a Sigstore client in the language the CLI is written with. For npm, that was sigstore-js
  2. Use a platform-provided feature

(1) is a lot of work and a barrier to entry. (2) seems a better option. A package CLI cannot call a GitHub Action. So there are 2 options for a CLI to take advantage of this Action:

  1. Ask users to split the npm publish (or equivalent for their package manager) into 2 step: cli create-package, then call the Action in this repo, then call cli publish-tarball.
  2. Let users call the GHA to set up a deamon that listens on a local port on the runner. When the daemon receives a request, it signs the artifact. The CLI then just needs to implement a REST API call to 127.0.0.1:port.

(1) does not seem great UX-wise, and may be complicated for certain ecosystems that create multiple files (Maven?).

So I was suggesting option (2). A GitHub Action (or this one with a specific --as-daemon option) that would listen to a local port and crate / sign attestation on demand. Users would add a step to their job before calling cli publish --with-provenance. Ideally this daemon could be enabled without a call to this Action, to further simplify UX.