Support public signing in private repositories

[gartnera]

We have a private repository but distribute our binaries publicly.

We would like for people to be able to validate the attestations of these binaries via the public good sigstore instances. There does not appear to be a way to push to the public good store from a private repository.

[bdehamer]

@gartnera you are correct, there is currently no supported way to attest artifacts built from private repos using the public-good Sigstore. When using the official attestation actions, private repo artifacts will always be attested using the GitHub Sigstore instance.

This ensures that sensitive data from private repositories doesn't end up on the public Sigstore transparency logs.

However, if you wanted to distribute the attestation bundles for your artifacts to your customers, they would be able to verify the attestation in the same way they would if it had been signed by public-good Sigstore. Clients would not be able to retrieve attestations directly from the GitHub attestations API without being given explicit permission to do so on your private repo, but if you wanted to distribute the attestations through some other channel everything should just work.

Worth noting that one of the primary benefits of attesting your artifacts is to provide traceability to how/where that artifact was built. If you're publishing attestations for artifacts which were built from a private repository, you're losing a good chunk of the value the attestation provides.

One work-around you could consider is to move your attestation workflow to a public repository that is triggered when the build on your private repo is complete.

[gartnera]

Ok so we just need to distribute the attestation bundles with the binaries, use the github trusted root (?), and disable transparency log verification.

Worth noting that one of the primary benefits of attesting your artifacts is to provide traceability to how/where that artifact was built. If you're publishing attestations for artifacts which were built from a private repository, you're losing a good chunk of the value the attestation provides.

I think there is still substantial value in proving that the binary was built on a trusted CI system with a specific commit hash. We have some third party auditors who publish their audit reports with a specific commit hash.

[bdehamer]

Assuming you're using the gh CLI to do your verification, everything should just work -- the CLI will look at the issuer of the certificate and determine the correct verification strategy (selecting the appropriate trusted root, enabling/disabling tlog verification, etc).

Here's an example of verification using a local attestation bundle:

$ gh attestation verify \
  oci://ghcr.io/bdehamer/memcached@sha256:24f3a0cf2e81f7e3cbfd4a736acf33c778991181afbacb2cc75fc665d3147647 \
  --owner bdehamer \
  --bundle ~/Downloads/attestation.sigstore.json

Loaded digest sha256:24f3a0cf2e81f7e3cbfd4a736acf33c778991181afbacb2cc75fc665d3147647 for oci://ghcr.io/bdehamer/memcached@sha256:24f3a0cf2e81f7e3cbfd4a736acf33c778991181afbacb2cc75fc665d3147647
Loaded 1 attestation from /Users/bdehamer/Downloads/bdehamer-attest-demo-attestation-1332394.sigstore.json
✓ Verification succeeded!

sha256:24f3a0cf2e81f7e3cbfd4a736acf33c778991181afbacb2cc75fc665d3147647 was attested by:
REPO                  PREDICATE_TYPE                  WORKFLOW                                       
bdehamer/attest-demo  https://slsa.dev/provenance/v1  .github/workflows/memcached.yml@refs/heads/main