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

[grahamc]

Just a +1 to being able to use the public good infra even on private repos. I understand the data we're leaking, and we think it is pretty much fine -- and that each team would need to decide for themselves.

Maybe it could work if there was a good documented set of example repos, which had an attestation from the private side be validated on the public side, then was re-attested on the public side?

...What would happen if we forked this repo, and just made it always use the public good instance?

[phillmv]

When designing this feature, we envisioned that most users would be deploying privately built binaries into privately controlled environments and we weren't sure how to adequately support this use case (private repo -> publicly distributed binaries). As a result, we decided to err on the side of maximizing privacy assurances. Private repo -> private attestation.

Using the public sigstore infrastructure doesn't buy you a ton since there is at present no easy paved path for verifying our attestations; you still need to distribute attestations to your end users.

@grahamc @gartnera I'd love to understand more about your use cases. How are you distributing your built artifacts? How are your end-users meant to deploy them? How are your end-users meant to verify them?

In the meantime, the following scenario could be an effective workaround:

• build your artifact as normal in example/private-repo
• host the built artifact as releases in example/public-repo
• have an Actions workflow in example/public-repo that:
  • pulls the artifact, and verifies the authenticity of the artifact: gh verify -R example/private-repo foo.bin
  • if the verification succeeds, attest it from the public-repo

This way your users will be able to verify your artifact via:

gh verify -o example foo.bin

Hope that helps,