actions / attest-build-provenance Goto Github PK
View Code? Open in Web Editor NEWAction for generating build provenance attestations for workflow artifacts
License: MIT License
Action for generating build provenance attestations for workflow artifacts
License: MIT License
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:
application/vnd.oci.image.index.v1+json
for multi-arch images)application/vnd.dev.sigstore.bundle.v0.3+json
), which links to the image manifest using an OCI Referrerhttps://in-toto.io/Statement/v1
)https://slsa.dev/provenance/v1
.For verification, you need to do the following:
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.
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:
actions/attest-build-provenance
to suppress the generation of the built-in job summaryactions/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 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:
id-token: write
)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?
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 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.
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 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-path
s, 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.
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.
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 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 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-path
s, 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
Its output should be improved - but I cannot find where is it coming from:
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
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.
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.
'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:
swiftlint.yml
was updated.swiftlint
on a project build that uses this dependencyChecklist - While not every PR needs it, new features should consider this list:
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.