actions / attest-build-provenance Goto Github PK

Hello,

I'm using the upload-artifact action to upload only a few selected files as artifacts, by using such a step:

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: com.obones.binding.openmeteo-openhab_${{ matrix.addons-ref }}-java_${{ matrix.java }}
          path: |
            openhab-addons/bundles/com.obones.binding.openmeteo/target/com.obones.binding.openmeteo*.jar
            !openhab-addons/bundles/com.obones.binding.openmeteo/target/com.obones.binding.openmeteo*-sources.jar

This allows to upload com.obones.binding.openmeteo-0.1.0.jar but not com.obones.binding.openmeteo-0.1.0-sources.jar as it is of no use in my case.

I tried using the same glob patterns on the attest-build-provenance step like this:

      - name: Create attestation
        uses: actions/attest-build-provenance@v1
        with:
          subject-path: |
            openhab-addons/bundles/com.obones.binding.openmeteo/target/com.obones.binding.openmeteo*.jar
            !openhab-addons/bundles/com.obones.binding.openmeteo/target/com.obones.binding.openmeteo*-sources.jar

But it still creates two attestations as can be seen here

Did I miss something?

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.

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.

https://github.com/stdedos/junit2html/actions/runs/10125546240

e.g. 0ae969cc78c6482b50ffafaa3d8875ebf5da011c70bf69305cf286f1517e5313 appears twice, but only once in the run logs

This might be tricky if the attestation store is append-only but, in the case of a rolling tag (let's name it early-access) which moves on a given period (let's say every push to main) the associated release points to the latest artifacts.

At the moment the attestations tab contains all attested artifacts according to the timeline, even if the artifact names are identical, see for example

https://github.com/jreleaser/jreleaser/attestations/1014782
https://github.com/jreleaser/jreleaser/attestations/1013783

In specific case for JReleaser's early-access release the tag & release overwrite any previously existing tag & release, thus there's only one active version of artifacts related to early-access. It would be good if attestations could also be overwritten. Due to the nature of attestations I suppose this behavior (if provided) should be guarded by a conditional flag and disabled by default.

Mh, should we really have two proto packages in the same dir. Maybe it's easiest to just have a prometheus package – we can break them up when we find them getting too busy.
The admin APIs are also in the prometheus package.

Originally posted by @fabxc in prometheus/prometheus#2850 (comment)

I'm

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

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?

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.

https://github.com/microsoft/azure-maven-archetypes/releases/tag/azure-functions-archetype-1.33

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.

Is it possible to build artifact in GHEC and validate attestation in GHES in air-gapped environment?

cbwallet://open?_branch_referrer=H4sIAAAAAAAAA0WKywqDMBREv0Z3jdWofYAUS%2FELug95VQMmN9wkhP5946owDMyZs8Xow71pViBSnDKRYBvFvX9IwbiMBtx0zLrMhPu0HXpF56pbSnLOJETuVDZxk%2Fj1EQjgepx0SdGyAAmlruhLgnGCB11148GtVibZwrMW9V%2Bc3phCZLNTCEaxJ0IOGmvGBHInN%2FbZITOjppbSYbhexlK39ty3fd%2F%2BAGqBNV7IAAAA&link_click_id=1335587655857487008

I'd like to disable the built-in job summary and instead generate my own attestation summary and combine it with the summary that I'm already generating for the job. In order to do this, I'd need to:

• pass a flag (or env variable) to actions/attest-build-provenance to suppress the generation of the built-in job summary
• obtain the attestation URL as an output of actions/attest-build-provenance (AFAICS the action doesn't currently provide this information)

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.

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?

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.

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.

For security reasons, id-token: write, attestations: write and other privilege usages should be minimized, so the privileges should not exist for code that performs "build" steps.

In other words, the best usage would be splitting the build+attest into separate steps:

1. build artifacts (without id-token: write)
2. attest the results

However, then the users would have to transfer the artifacts from build to the attest job.
Of course they can make a zip file, publish it from "build artifacts", download it in the attest job, and perform the attestation.
That would be wasteful though as the only needed bit is SHA of the file, so it would be better to generate a list of filename-checksum pairs in the "build artifact" job, and use the list in "attest the results" job.

What do you think of adding @actions/upload-checksums action that would generate checksums for the specified files. Then @actions/attest-build-provenance could use the list and generate the attestations for them?

whatwg/spec-factory@614b23f

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.

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

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.

We have a job-global environment variable that is successfully used in other build steps, but that does not get expanded as part of defined subject-paths, see this error.

Is some special syntax required, or is this another restriction of actions/glob?

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!

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.

Error: InternalError: error creating signing certificate
FetchError: network timeout at: https://fulcio.sigstore.dev/api/v2/signingCert

this was working, but now isn't.

I see some "2 minutes" of downtime on the status page for sigstore.dev....but,it says all are ok, but also some red, and I can't see any detail.

no incidents reported:

After being able to create several attestations, my workflow using this action has now two times in a row failed due to the following error:

Run actions/attest-build-provenance@v[1](https://github.com/hydephp/cli/actions/runs/9466300050/job/26077668879#step:16:1)
Run actions/attest-build-provenance/predicate@db1dde0f270afe12073070ac7aa802958ae3ec04
Run actions/attest@32795ed9174327efe1734fa[6](https://github.com/hydephp/cli/actions/runs/9466300050/job/26077668879#step:16:7)d09c9223658ef225
  
Error: InternalError: error creating tlog entry - (409) an equivalent entry already exists in the transparency log with UUID 24296fb24b8ad[7](https://github.com/hydephp/cli/actions/runs/9466300050/job/26077668879#step:16:9)7ad1462c39db32ce379b402445ee1bfb00546e4d127500853b563c821125437692
Error: (409) an equivalent entry already exists in the transparency log with UUID 24296fb24b8ad77ad[14](https://github.com/hydephp/cli/actions/runs/9466300050/job/26077668879#step:16:16)62c39db32ce379b402445ee1bfb00546e4d127500853b563c821125437692

Action run logs: https://github.com/hydephp/cli/actions/runs/9466300050/job/26077668879

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

Thanks for this action and all the work on the whole infrastructure setup. 🙂

I'm just starting to attempt to generate SBOM and provenance attestations (this part using this action), sign my images and push them to the registry. I've been working with a test image of one of our projects: grafana/wait-for-github:iainlane-attestation-test (here is the latest build log).

gh attestation verify works:

laney@melton> GH_DEBUG=1 gh attestation verify -R grafana/wait-for-github oci://grafana/wait-for-github:iainlane-attestation-test
Loaded digest sha256:360587aa9781d76b825f65f56f40738ceaf79b5ef5996b4b121c7544c9f7d662 for oci://grafana/wait-for-github:iainlane-attestation-test
Fetching attestations for artifact digest sha256:360587aa9781d76b825f65f56f40738ceaf79b5ef5996b4b121c7544c9f7d662

* Request at 2024-07-26 08:59:09.609515 +0100 BST m=+0.939990460
* Request to https://api.github.com/repos/grafana/wait-for-github/attestations/sha256:360587aa9781d76b825f65f56f40738ceaf79b5ef5996b4b121c7544c9f7d662?per_page=30
* Request took 254.894208ms
Loaded 1 attestation from GitHub API
Verifying attestation 1/1 against the configured Sigstore trust roots
Attempting verification against issuer "sigstore.dev"
SUCCESS - attestation signature verified with "sigstore.dev"

✓ Verification succeeded!

sha256:360587aa9781d76b825f65f56f40738ceaf79b5ef5996b4b121c7544c9f7d662 was attested by:
REPO                     PREDICATE_TYPE                  WORKFLOW                                       
grafana/wait-for-github  https://slsa.dev/provenance/v1  .github/workflows/build.yml@refs/pull/130/merge

What I'm wondering is how to do the same using cosign. In the build log I can see:

Attestation uploaded to registry
index.docker.io/grafana/wait-for-github@sha256:1fdab504a0700ee12b2537d75d329bee920a88a1f96ee5b20fa9cb749bfc213b

And indeed I can see this reference with e.g. docker buildx imagetools inspect. But when I try to verify or download the attestation I end up with a 404:

laney@melton> cosign --verbose download attestation grafana/wait-for-github:iainlane-attestation-test
# ...
2024/07/26 09:02:35 --> GET https://index.docker.io/v2/grafana/wait-for-github/manifests/sha256-360587aa9781d76b825f65f56f40738ceaf79b5ef5996b4b121c7544c9f7d662.att
2024/07/26 09:02:35 GET /v2/grafana/wait-for-github/manifests/sha256-360587aa9781d76b825f65f56f40738ceaf79b5ef5996b4b121c7544c9f7d662.att HTTP/1.1
Host: index.docker.io
User-Agent: cosign/v2.3.0 (darwin; arm64) go-containerregistry/v0.20.1
Accept: application/vnd.docker.distribution.manifest.v1+json,application/vnd.docker.distribution.manifest.v1+prettyjws,application/vnd.docker.distribution.manifest.v2+json,application/vnd.oci.image.manifest.v1+json,application/vnd.docker.distribution.manifest.list.v2+json,application/vnd.oci.image.index.v1+json
Authorization: <redacted>
Accept-Encoding: gzip


2024/07/26 09:02:35 <-- 404 https://index.docker.io/v2/grafana/wait-for-github/manifests/sha256-360587aa9781d76b825f65f56f40738ceaf79b5ef5996b4b121c7544c9f7d662.att (95.813542ms)
2024/07/26 09:02:35 HTTP/1.1 404 Not Found
Content-Length: 169
Content-Type: application/json
Date: Fri, 26 Jul 2024 08:02:35 GMT
Docker-Distribution-Api-Version: registry/2.0
Docker-Ratelimit-Source: redacted
Strict-Transport-Security: max-age=31536000

{"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest unknown","detail":"unknown tag=sha256-360587aa9781d76b825f65f56f40738ceaf79b5ef5996b4b121c7544c9f7d662.att"}]}

Error: found no attestations
main.go:74: error during command execution: found no attestations

With my naive understanding, it looks like it's not being found from the tag's manifest. Am I doing something wrong, or is this not expected to work currently?

To make this an issue rather than a question --- if this is possible to do, it'd be a nice example to have in the README 🙂

Hi,

I am trying to use this action in one of my self-hosted ARC runners, but I get this error:
Error: Failed to get ID token: error in secret or public key callback: socket hang up

I have been checking the action code to see if I could figure out what could be causing the issue, but I am a little bit lost. It seems to be related to the action not being able to get an ID Token from GitHub, but I struggle to see why.

These are the permissions given to the workflow:

permissions:
      id-token: write
      contents: read
      attestations: write

This is how I am using the action in the workflow:

- name: Attest
   uses: actions/attest-build-provenance@v1
   id: attest
   with:
       subject-name: ${{ inputs.REGISTRY_SERVER }}/${{ inputs.APP_NAME }}
       subject-digest: ${{ steps.get-image-digest.outputs.imageDigest }}
       push-to-registry: true

I can also see that my runner has ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN envs set, and that there seems to be connectivity from the runner to the URL specified in the env

sh-4.4$ curl -v https://pipelinesghubeus13.actions.githubusercontent.com/HF......
....
< HTTP/1.1 401 Unauthorized

401 response code is expected as I am not using the token in the curl request.

Any idea about what could be causing this issue?

PS: Other actions that make use of GH ID token work as expected. In the same workflow I am using aws-actions/configure-aws-credentials and that works perfectly fine.

Thanks in advance!

l

The action does not find these paths, see this error, although the step before does find the same paths, so something seems to be wrong with wildcard / glob expansion and multiple paths.

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.

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.

We have a job-global environment variable that is successfully used in other build steps, but that does not get expanded as part of defined subject-paths, see this error.

Is some special syntax required, or is this another restriction of actions/glob?

Originally posted by @sschuberth in #146

The dynamic output format that looks like

<h3>Attestations Created</h3>
<a href="https://github.com/a/b/attestations/1368115">b_ SNAPSHOT-v0.4.0-1-g2246b21_Darwin_arm64.tar.gz@sha256:509</a>
<a href="https://github.com/a/b/attestations/1368116">b_ SNAPSHOT-v0.4.0-1-g2246b21_Darwin_x86_64.tar.gz@sha256:e80</a>
<a href="https://github.com/a/b/attestations/1368117">b_ SNAPSHOT-v0.4.0-1-g2246b21_Linux_arm64.tar.gz@sha256:b24</a>
<a href="https://github.com/a/b/attestations/1368118">b_ SNAPSHOT-v0.4.0-1-g2246b21_Linux_i386.tar.gz@sha256:103</a>
<a href="https://github.com/a/b/attestations/1368119">b_ SNAPSHOT-v0.4.0-1-g2246b21_Linux_x86_64.tar.gz@sha256:37d</a>
<a href="https://github.com/a/b/attestations/1368120">b_ SNAPSHOT-v0.4.0-1-g2246b21_Windows_arm64.zip@sha256:714</a>
<a href="https://github.com/a/b/attestations/1368121">b_ SNAPSHOT-v0.4.0-1-g2246b21_Windows_i386.zip@sha256:036</a>
<a href="https://github.com/a/b/attestations/1368122">b_ SNAPSHOT-v0.4.0-1-g2246b21_Windows_x86_64.zip@sha256:2ac</a>

does not render "correctly" even on Github-commonmark

Attestations Created

(for posterity:)

Its output should be improved - but I cannot find where is it coming from:

• It's not from this repo https://github.com/search?q=repo%3Aactions%2Fattest-build-provenance%20Attestations%20Created&type=code
• Or its "binary": https://github.com/search?q=repo%3Aactions%2Ftoolkit%20Attestations%20Created&type=code

The ACTIONS_ID_TOKEN_REQUEST_URL env variable appears to be unavailable if this action is run on a pull request from a fork into an upstream branch.

It works perfectly fine when ran in the fork itself, or if the pull request is from a branch belonging to the upstream repository itself. It could be my mistake with configuration, or just a misunderstanding of how the action is supposed to work on my part. It'd be great if a fix could be provided for this, or at least a workaround where for this specific situation the step is skipped.

Here is an example of a run with the situation I'm describing: https://github.com/RimSort/RimSort/actions/runs/9338649185

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

Resolve SwiftLint warning: 'variable_name' has been renamed to 'identifier_name' and will be completely removed in a future release.

The PR should summarize what was changed and why. Here are some questions to
help you if you're not sure:

• What behavior was changed?
  • A SwiftLint rule was updated to use its new name. This is a refactor and does not affect the runtime behavior.
• What code was refactored / updated to support this change?
  • Only swiftlint.yml was updated.
• What issues are related to this PR? Or why was this change introduced?
  • Resolve a SwiftLint warning when running swiftlint on a project build that uses this dependency

Checklist - While not every PR needs it, new features should consider this list:

• Does this have tests?
  • n/a
• Does this have documentation?
  • n/a
• Does this break the public API (Requires major version bump)?
  • no
• Is this a new feature (Requires minor version bump)?
  • This is not a functional change. I will leave it up to the maintainers to decide if it really needs to be released by itself. But I think there should not be any issues as long as it makes it in to the next release.

Originalmente postado por @fraune em SwiftyJSON/SwiftyJSON#1160

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