actions / attest-build-provenance Goto Github PK

Expected Behavior

Provenances created with this action can be found on sigstore, by searching for the subject's digest on https://search.sigstore.dev/?hash=. The corresponding entry there displays the full provenance. This is the case for provenances created using the slsa-github-generator action. Eg see this workflow run and its corresponding rekor entry.

Actual Behavior

One may find an entry for provenances created with this action. Eg see this workflow run and its corresponding entry on sigstore's rekor, found via this search. However, the entry on rekor does not show the actual provenance.

cc @thmsbinder, @tiziano88

Hi, I tried to verify the build provenance using the cosign tool, but this does not seem to be compatible (yet).

Is there any technical spec regarding how the provenance attestation data is encoded and added to the container registry? From a quick tests, it looks like the the attest-build-provenance action does the following:

• The attestation data is added to the OCI v2 registry next to the image manifest (application/vnd.oci.image.index.v1+json for multi-arch images)
• The attestation data itself is a sigstore v0.3 bundle (application/vnd.dev.sigstore.bundle.v0.3+json), which links to the image manifest using an OCI Referrer
• The payload of the sigstore bundle contains the in-toto statement ( https://in-toto.io/Statement/v1 )
• The predicate contains the gh action provenance data as https://slsa.dev/provenance/v1.

For verification, you need to do the following:

• get the digest of the container (the manifest / index)
• get the referrer by type for the manifest / index

The downloaded data is a sigstore v0.3 bundle, whereby the .dsseEnvelope.payload contains the in-toto Statement v1. The subject hereby points to the image manifest digest. The predicate contains the provenance v1 data and the signature can be checked by verifying the integrity of the DSSE.

Using https://github.com/docker/bake-action and https://docs.docker.com/build/bake/ it is possible to build multiple container images in a single pipeline execution.

I have a pipeline where I am building dozens of images and would like to be able to attest them but it looks like i would have to run a matrix based approach which would consume many runners and isn't very efficient use of our self hosted runners, it would be ideal if i can pass a list of images & digests to attest.

Hello,

I got very excited but your latest announcement at https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/ and I was wondering, since now you've established your own CA, is there any plan to sign Windows binaries to at least allow FOSS projects bypass the Windows consent screen and false-positive warnings in Windows Defender ( and most anti viruses anyway )?
Basically an alternative to https://signpath.org/about/ but made in Github.

I see this action fitting this purpose perfectly, but as I see nothing mentioned around Windows I thought it would be worth to ask anyway.

Thank you in advance and best regards,
Julian

If I understand correctly, we need to attest each file one by one. This is a bit annoying if your workflow builds artifacts for several architectures/operating systems. It would be great to be able to specify multiple files at once.

Thank you 🙇‍♀ for wanting to create an issue in this repository. Before you do, please ensure you are filing the issue in the right place. Issues should only be opened on if the issue relates to code in this repository.

• If you have found a security issue please submit it here
• If you have questions about writing workflows or action files, then please visit the GitHub Community Forum's Actions Board
• If you are having an issue or question about GitHub Actions then please contact customer support

If your issue is relevant to this repository, please delete this text and continue to create this issue. Thank you in advance.

From the README:

If the repository initiating the GitHub Actions workflow is public, the public-good instance of Sigstore will be used to generate the attestation signature. If the repository is private/internal, it will use the GitHub private Sigstore instance.

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?

I have tried attesting the Docker images built by my GitHub Actions workflow and pushed to ghcr.io.

I have tried using the documentation here and here.

I have the following workflow steps (source here):

env:
  # Use docker.io for Docker Hub if empty
  REGISTRY: ghcr.io
  # github.repository as <account>/<repo>
  IMAGE_NAME: ${{ github.repository }}
....
      # Login against a Docker registry except on PR
      # https://github.com/docker/login-action
      - name: Log into registry ${{ env.REGISTRY }}
        if: github.event_name != 'pull_request'
        uses: docker/[email protected]
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      # Extract metadata (tags, labels) for Docker
      # https://github.com/docker/metadata-action
      - name: Extract Docker metadata
        id: meta
        uses: docker/[email protected]
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          labels: |
            org.opencontainers.image.title=Minetest Skin Server

      # Build and push Docker image with Buildx (don't push on PR)
      # https://github.com/docker/build-push-action
      - name: Build and push Docker image
        id: build-and-push
        uses: docker/[email protected]
        with:
          context: .
          platforms: linux/amd64,linux/arm64,linux/386,linux/ppc64le,linux/s390x
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
          no-cache: ${{ !inputs.use_cache || startsWith(github.ref, 'refs/tags/') }}

      - name: Attest Build Provenance
        if: github.event_name != 'pull_request'
        uses: actions/[email protected]
        with:
          subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          subject-digest: ${{ steps.build-and-push.outputs.digest }}
          push-to-registry: true

But the attestation step is failing (full workflow logs):

Run actions/[email protected]
Run actions/attest-build-provenance/predicate@db1dde0f270afe12073070ac7aa802958ae3ec04
  
Run actions/attest@32f49af6653ef9b7d1a40182d53fc9ebd53447d8
  
Attestation created for ghcr.io/AFCMS/minetest-skin-server@sha256:36d352f719ccc088efcecf585bb8c93f1588efd896e93d68e78f3f3bfa0751ce
Attestation signed using certificate from Public Good Sigstore instance
Attestation signature uploaded to Rekor transparency log
https://search.sigstore.dev?logIndex=93072090
Attestation uploaded to repository
https://github.com/AFCMS/minetest-skin-server/attestations/82[95](https://github.com/AFCMS/minetest-skin-server/actions/runs/9051166171/job/24867371956#step:8:98)14
Error: Error: Invalid image name: ghcr.io/AFCMS/minetest-skin-server

I don't know why, because I followed exactly the steps in the docs, and if the image name was invalid it should already fail in the build step?

For workflows that allow user input upon invocation, such as via the workflow_dispatch event, the provenance should include the user-supplied inputs in the externalParameters section. We could also consider the event type as an externalParameter.

example workflow_dispatch provenance

SLSA's Provenance Spec has some guidance about the externalParameters, with some ambiguity about whether they are required for Level 2 or for Level 3. This could be a typo, because Level 3's emphasis can be summarized as isolation between the builder and signer environments.

https://slsa.dev/spec/v1.0/provenance#model

externalParameters: the external interface to the build. In SLSA, these values are untrusted; they MUST be included in the provenance and MUST be verified downstream.

https://slsa.dev/spec/v1.0/provenance#builddefinition

The parameters that are under external control, such as those set by a user or tenant of the build platform. They MUST be complete at SLSA Build L3, meaning that that there is no additional mechanism for an external party to influence the build. (At lower SLSA Build levels, the completeness MAY be best effort.)

I understand that, for now, Github's attestation Action intends to be at Level 2, but it's worth including this for users that do happen to use workflow inputs as actual build parameters.

... Artifact attestations provides SLSA v1.0 Build Level 2.

Thanks for the new action (I have been playing around with it since this morning with my repositories), I noticed the action fails when passing multiple glob objects i.e. subject-path: 'language_archives/**/*.zip, scripts/pdf/**/*.pdf' (or) 'language_archives/**/*.zip', 'scripts/pdf/**/*.pdf'.

Allowing this syntax would allow attesting only specific file types from the build process and would also prevent redundant usage like:

    - name: Attest generated Zip files
      if: env.zip_exists == 'true'
      uses: actions/attest-build-provenance@v1
      with:
        subject-path: 'language_archives/**/*.zip'

    - name: Attest generated PDF files
      if: env.pdf_exists == 'true'
      uses: actions/attest-build-provenance@v1
      with:
        subject-path: 'scripts/pdf/**/*.pdf'

For full workflow reference, feel free to check out this permalink. I am evaluating the action to eventually propose adding it to tldr-pages where I am one of the maintainers.

I followed this guide to add a workflow for publishing an image with an attestation.

The build-push step successfully pushed to this Hub repo with this workflow. It's failing at the attestation step with "Error uploading artifact to container registry."

Run actions/attest-build-provenance@v1
Run actions/attest-build-provenance/predicate@db1dde0f270afe12073070ac7aa802958ae3ec04
  
Run actions/attest@d442d85e120905fa5821e76edb1e07a75b94ee7a
  
Attestation created for docker.io/***/ziti-console-assets@sha256:fbc45cffeb4effc49260f09f1a4e12041320fdb0e68f34f6d3f4ef508216bdf2
Attestation signed using certificate from Public Good Sigstore instance
Attestation signature uploaded to Rekor transparency log
https://search.sigstore.dev?logIndex=92703814
Attestation uploaded to repository
https://github.com/qrkourier/ziti-console/attestations/822597
Error: Error uploading artifact to container registry

build log from run: https://github.com/qrkourier/ziti-console/actions/runs/9035775334/job/24831227577

Here's my job step.

jobs:
  docker-build-push:
    steps:
# ...snip...
        - name: Generate artifact attestation
          uses: actions/attest-build-provenance@v1
          with:
            subject-name: docker.io/kbinghamnetfoundry/ziti-console-assets
            subject-digest: ${{ steps.push.outputs.digest }}
            push-to-registry: true

Thank you for your help.

I'm

Originally posted by @akavandal88 in akavandal88/Katie-Kinosian#1 (comment)

Does actions/attest-build-provenance@v1 support Google Artifact Registry?

The build-push step successfully pushed image to Google Artifact Registry with this workflow at Build the integration test server container and push to the registry. It's failing at the attestation step with Error: OCIError: Error uploading artifact to container registry Error: Error fetching https://us-central1-docker.pkg.dev/v2/<repoA>/<imageA>/manifests/sha256:xxxxxxx - expected 200, received 404

Here's my job step.

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      attestations: write
      packages: write
    env:
      file: './python-hello-world/Dockerfile'
      run_from: './python-hello-world'

    steps:
      - name: 'Checkout'
        uses: 'actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11' # ratchet:actions/checkout@v4

      # Authenticate to GCP with WIF
      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@55bd3a7c6e2ae7cf1877fd1ccb9d54c0503c457c' # ratchet:google-github-actions/auth@v2
        with:
          workload_identity_provider: '${{ env.WIF_PROVIDER }}'
          service_account: '${{ env.WIF_SERVICE_ACCOUNT }}'
          token_format: 'access_token'

      - name: 'Authenticate to Artifact Registry'
        uses: 'docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d' 
        with:
          username: 'oauth2accesstoken'
          password: '${{ steps.auth.outputs.access_token }}'
          registry: 'us-central1-docker.pkg.dev'

      # Build and Push Image
      - name: 'Build the integration test server container and push to the registry'
        id: push
        uses: 'docker/build-push-action@4a13e500e55cf31b7a5d59a38ab2040ab0f42f56'
        with:
          push: true
          tags: '${{ env.DOCKER_REPO }}/${{ env.IMAGE_NAME }}:${{env.DOCKER_TAG}}'
          file: '${{ env.file }}'
          context: '${{ env.run_from }}'

      - name: Generate artifact attestation
        uses: actions/attest-build-provenance@v1
        with:
          subject-name: '${{ env.DOCKER_REPO }}/${{ env.IMAGE_NAME }}' // example is `us-central1-docker.pkg.dev/repoA/imageA`
          subject-digest: '${{ steps.push.outputs.digest }}'
          push-to-registry: true

Looks like actions/attest-build-provenance@v1 doesn't use the auth I provided in previous step automatically and it doesn't expose a way to configure the auth needed for Google Artifact Registry. The previous steppush which push the image to the Google Artifact Registry works, so I'm pretty sure I'm providing the correct auth for Google Artifact Registry.

At the same time, I also run curl -H "Authorization: Bearer $(gcloud auth print-access-token)" https://us-central1-docker.pkg.dev/v2/<repoA>/<imageA>/manifests/sha256:xxxxxxx for the url throw in the error message Error fetching https://us-central1-docker.pkg.dev/v2/<repoA>/<imageA>/manifests/sha256:xxxxxxx - expected 200, received 404, and the curl works which shows the https://us-central1-docker.pkg.dev/v2/<repoA>/<imageA>/manifests/sha256:xxxxxxx is a valid url.

Thank you for your help!

Hey,

I am building a docker image with a lot of tags with docker/build-push-action@v5, It would be nice if I could pipe the same list to this action to add the build-provenance to all tags at once.

Kinda like this:

      - id: push
        uses: docker/build-push-action@v5
        with:
          tags: |
            ${{ matrix.caddy-tags }}
          //....

      - name: Attest
        uses: actions/attest-build-provenance@v1
        id: attest
        with:
          subject-name: |
            ${{ matrix.caddy-tags }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

I use Google Cloud Artifactory Registry and the google auth action. This action adds a credential helper to the docker config file, but I get Error: No credentials found for registry europe-west4-docker.pkg.dev:

Run gcloud auth configure-docker europe-west4-docker.pkg.dev

Adding credentials for: europe-west4-docker.pkg.dev
After update, the following will be written to your Docker config file located 
at [/home/runner/.docker/config.json]:
 {
  "credHelpers": {
    "europe-west4-docker.pkg.dev": "gcloud"
  }
}

Error:

Run actions/attest-build-provenance@v1
Run actions/attest-build-provenance/predicate@db1dde0f270afe12073070ac7aa802958ae3ec04
Run actions/attest@12c083815ed46d5d78222e3824f4a26c42c234d3
Attestation created for europe-west4-docker.pkg.dev/***/composetodo-repo/todo@sha256:9c9e5d7262be6bc0ead3bbf6b01dbfa8557d0a0e6108f0a285d3f39efde1d1fa
Attestation signed using certificate from Public Good Sigstore instance
Attestation signature uploaded to Rekor transparency log
[https://search.sigstore.dev?logIndex=94477234](https://search.sigstore.dev/?logIndex=94477234)
Attestation uploaded to repository
https://github.com/hfhbd/ComposeTodo/attestations/859947
Error: Error: No credentials found for registry europe-west4-docker.pkg.dev

Job log: https://github.com/hfhbd/ComposeTodo/actions/runs/9118458625/job/25071641672

Hi, while working on a container cleanup action (a proper one, not the package eater delete-package-versions), I noticed that special handling of the attestation data is required: The attestations are tagged according to the OCI spec v1 fallback defined in the cosign bundle spec, even when working on OCI spec v2 registries.

The problem hereby is, that the attestation manifests are tagged with sha256-<digest>, which makes them tagged images where special handling is needed. For OCI v2 registries (which support the referrers API), this is not needed (and discouraged), as the relation between the container and the attestation is purely done based on the "subject" part in the attestation manifest. This is picked up by the referrers API.

My proposal is to detect if the registry supports the referrers API (https://github.com/oras-project/artifacts-spec/blob/main/manifest-referrers-api.md#api-discovery) and conditionally create the tags.

Xref: dataaxiom/ghcr-cleanup-action#13

Here's a build when using actions/attest-build-provenance: https://github.com/SteamDatabase/SteamTokenDumper/actions/runs/9176712362

And here's one when it was reverted: https://github.com/SteamDatabase/SteamTokenDumper/actions/runs/9180820690

For some reason it takes over 30 minutes for the job finish, but none of the steps take that long.