Open alexrp opened 6 months ago
We don't have a good way to support this use case currently. The identity which is embedded in the attestation is derived from the repository associated with the workflow. This means that the repository and git commit referenced in the provenance attestation would refer to the private build repo, not the public source repo.
To leverage provenance attestations today you'd have to co-locate your source code and your build workflow in the same repository.
Could this realistically be supported in the future? Or is this fundamental to how attestation works?
I think that it may be possible to support something like this in the future, but will probably require that attestation support get baked-in to the GitHub Actions system as a first-class feature. In it's current form, the provenance attestation really requires that the source and the build workflow be located in the same repository.
Noting that this also affects workflows that use a reusable workflow from another repo to create the attestation. The attestation refers to the reusable workflow rather than the workflow that used it, and if that exists in another repo then the attestation won't be verifiable.
@johnbillion I think the use case you're describing is a bit different. We definitely support verification of attestations created with reusable workflows from different repositories. See the information about using the --signer-repo
and --signer-workflow
flags here.
@bdehamer Thanks!
I think so
From the README:
I have an organization where we have repo A (public, containing all the source code) and repo B (private, containing deployment workflows, scripts, etc). When we want to trigger a release, repo B builds artifacts and uploads them to a release on repo A using a custom
GITHUB_TOKEN
.In this setup, we would like to create the attestations in repo A, rather than in repo B (and so use the public-good instance). To my understanding, this is not possible right now?