sigstore / cosign-installer

Cosign Github Action

sigstore framework

sigstore/sigstore contains common Sigstore code: that is, code shared by infrastructure (e.g., Fulcio and Rekor) and Go language clients (e.g., Cosign and Gitsign).

This library currently provides:

• A signing interface (support for ecdsa, ed25519, rsa, DSSE (in-toto))
• OpenID Connect fulcio client code

The following KMS systems are available:

• AWS Key Management Service
• Azure Key Vault
• HashiCorp Vault
• Google Cloud Platform Key Management Service

For example code, look at the relevant test code for each main code file.

Fuzzing

The fuzzing tests are within https://github.com/sigstore/sigstore/tree/main/test/fuzz

Security

Should you discover any security issues, please refer to sigstores security process

For container signing, you want cosign

cosign-installer's Issues

Feature/design: Version selection

We should figure out how to configure which cosign version is used in the action, including ways to verify those releases.

It's a bit of a bootstrapping problem, since we don't have anything to verify cosign with until it's been installed. A tampered binary can't be trusted to verify itself :)

Maybe we hardcode a specific "bootstrap" version in the action by digest (like we have today). Then that version installs and verifies the next one, if the user wants a specific one. We have to trust that bootstrap one, but we can try to build it reproducibly (if it's not already) and document the reproduction steps so anyone can download the source at that version and get the same digest.

Test

Description

cosign v2 installation

Description

It'd be great to support v2 installation for cosign-installer. I was planning to start using cosign v2 flags for certain testing purposes.

Change version string of cosign-installer to be different than underlying cosign

Any chance we can decouple the version of cosign-installer from the version of cosign that is being installed?

provide an option or specific version name to download cosign via go install command

Description

in setup-ko project there is a special version name called tip which allows us to install ko via go install from main. It'd be helpful to people who might want to work with the latest changes of the cosign before waiting for its newer version.

v1.4.0 not available

Question

I have been using v1.4.0, but it is suddenly unavailable, the error message is as follows, what should I do?

Support the runner context of gitea act

Description
x64 Gitea act runner uses a bit different context values for arch and os.

• runner.os is lower case
• runner.arch is amd64 for X64.

signing image always fail with multuple stage docker build

Description

recently I added a golang docker build for a project, but it always fail in signing process, error log:

Run cosign sign ghcr.io/LeoQuote/custom-error-page@sha256:f48b41f7085b07cfbd5fde9f56712aa08971caf858bf3a03eaed0f366650c566
Generating ephemeral keys...
Retrieving signed certificate...
client.go:194: root pinning is not supported in Spec 1.0.19
Successfully verified SCT...
Error: signing [ghcr.io/LeoQuote/custom-error-page@sha256:f48b41f7085b07cfbd5fde9f56712aa08971caf858bf3a03eaed0f366650c566]: parsing reference: could not parse reference: ghcr.io/LeoQuote/custom-error-page@sha256:f48b41f7085b07cfbd5fde9f56712aa08971caf858bf3a03eaed0f366650c566
main.go:46: error during command execution: signing [ghcr.io/LeoQuote/custom-error-page@sha256:f48b41f7085b07cfbd5fde9f56712aa08971caf858bf3a03eaed0f366650c566]: parsing reference: could not parse reference: ghcr.io/LeoQuote/custom-error-page@sha256:f48b41f7085b07cfbd5fde9f56712aa08971caf858bf3a03eaed0f366650c566
Error: Process completed with exit code 1.

here's the project using the action : https://github.com/LeoQuote/custom-error-page/pull/1/files

everything else seems to be fine. the image has been push, except image signing

Update cosign version to v1.1.0

Hi,

With the new release of cosign, the new default of the installer should be v1.1.0.

Action as verified in the github marketplace

Description

Hi, is it possible to verify the action in the marketplace, according to this issue from sealed-secrets project ?
There is a link to have more information about marketplace verification.

It's seems sigstore is already verified by github.

Thank you in advance

xargs is not required to do keyless signing with GH OIDC token

The documentation in the README suggests using xargs to sign containers/blobs without a key.
This is not needed and add complexity to the command.

I was able to sucessfully sign images from a GH action workflow with the following step:

- name: Sign the images with GitHub OIDC Token
      env:
        IMAGE: {{ env.IMAGE_REGISTRY}}/${{ env.REGISTRY_USER}}/${{ env.IMAGE_NAME }}
      run: | 
        cosign sign \
        -a "repo=${{ github.repository }}" \
        -a "workflow=${{ github.workflow }}" \
        -a "ref=${{ github.sha }}" \
        --yes ${IMAGE}@${DIGEST}

I drew inspiration from there : https://github.com/sigstore/cosign/blob/main/scripts/sign-images-ci.sh

Skip install if cosign is already installed

Description

We are using custom build self-hosted runner, and using cosign to sign our internal container images.
As this action runs every workflow that we build our image, it would be helpful to reduce build time and data transfer when we cache cosign binaries. but it seems current install script doesn't check preinstalled cosign binary and downloads binary everytime it runs.

Where and how to store encrypted private key?

Question

I'm using github actions and goreleaser combined with cosign - works great! My question is about the location of the encrypted private key. In the documentation the cosign command expects the encrypted private key to be at the root of my repo.

Should I be committing the encrypted private key to my repo? Should I be getting the private key into a file on disk before goreleaser runs in my action some other way? If so is there a prescribed way of doing this?

enable users to speficy where they want to install cosign

Description

By default cosign will be installed into the directory $HOME/.cosign, maybe we can accept a variable from users to let them specify where they want to install cosign binary.

WDYT @Dentrax @cpanato?

Downloading sig and pubfile in project root leaves dirty git state

Description

When downloading the sig and pub files in the root of a project, it should be cleaned up after check or moved with the binary in the .cosign folder

cosign-installer/action.yml

Lines 59 to 68 in bafe473

	curl -L https://github.com/sigstore/cosign/releases/download/${{ inputs.cosign-release }}/cosign_linux_amd64_0.6.0_linux_amd64.sig -o cosign-linux-amd64.sig
	else
	curl -LO https://github.com/sigstore/cosign/releases/download/${{ inputs.cosign-release }}/cosign-linux-amd64.sig
	fi
	if [[ ${{ inputs.cosign-release }} < 'v0.6.0' ]]; then
	curl -L https://raw.githubusercontent.com/sigstore/cosign/${{ inputs.cosign-release }}/.github/workflows/cosign.pub -o release-cosign.pub
	else
	curl -LO https://raw.githubusercontent.com/sigstore/cosign/${{ inputs.cosign-release }}/release/release-cosign.pub
	fi
	./cosign verify-blob -key release-cosign.pub -signature cosign-linux-amd64.sig cosign_${{ inputs.cosign-release }}

otherwhise tools like goreleaser complain about the dirty state of the project during the release process.

cosign installer removes cosign.pub from the root of project causing dirty state for goreleaser

Description

This is my cosign installer block:

      -
        name: Install cosign
        uses: sigstore/cosign-installer@main
        with:
          cosign-release: 'v1.1.0'

After it runs, my git state is dirty and goreleaser fails with the following error:

 ⨯ release failed after 0.02s error=git is currently in a dirty state, please check in your pipeline what can be changing the following files:
 D cosign.pub

I've placed a tmate debug before the action and then after to confirm that something in this action is dirtying the state.

unsupported pem type: ENCRYPTED SIGSTORE PRIVATE KEY

Description
Hello,
It is my first use of consign, I tried to check if any mention of this issue was reported but nothing found. And the error message is not really helping to understand what could be the cause.

the error says:
getting signer: reading key: unsupported pem type: ENCRYPTED SIGSTORE PRIVATE KEY

No idea about the potential reason of this issue. I regenerated the keypair at least three times.
I also tried without a key password since the meesage seems about the key decryption part, but the issue remains

Version

3.2.0

My current workflow

https://github.com/soubinan/xoa-container/blob/main/.github/workflows/build.yml

name: Container Image Build and Sign

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]
  release:
    types: [published]

env:
  IMAGE_NAME: soubinan/xoa-container
  TEST_TAG: soubinan/xoa-container:test
  PROJECT_URL: https://github.com/soubinan/xoa-container
  AUTHOR: https://github.com/soubinan

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Get xo-server version
        id: xo-server
        run: |
          echo "XO_SERVER="$(curl -s https://raw.githubusercontent.com/vatesfr/xen-orchestra/master/packages/xo-server/package.json | jq -r ".version") >> $GITHUB_ENV
      - name: Get xo-web version
        id: xo-web
        run: |
          echo "XO_WEB="$(curl -s https://raw.githubusercontent.com/vatesfr/xen-orchestra/master/packages/xo-web/package.json | jq -r ".version") >> $GITHUB_ENV
      - name: Checkout
        uses: actions/[email protected]
      - name: Docker meta
        id: meta
        uses: docker/[email protected]
        with:
          images: |
            ghcr.io/${{ env.IMAGE_NAME }}
          tags: |
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=semver,pattern={{major}}
            type=raw,latest
          labels: |
            org.opencontainers.image.source=${{ env.PROJECT_URL }}
            org.opencontainers.image.url=${{ env.PROJECT_URL }}
            org.opencontainers.image.title=XOA-Container
            org.opencontainers.image.documentation=${{ env.PROJECT_URL }}
            org.opencontainers.image.authors=${{ env.AUTHOR }}
            org.opencontainers.image.licenses=CC-BY-NC
      - name: Install cosign
        if: github.event_name == 'release'
        uses: sigstore/[email protected]
        with:
          cosign-release: main
      - name: Set up Docker Buildx
        uses: docker/[email protected]
      - name: Login to Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GHP }}
        if: github.event_name == 'release'
      - name: Build and push
        id: build-and-push
        uses: docker/[email protected]
        with:
          context: "."
          file: "./Containerfile"
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          annotations: ${{ steps.meta.outputs.annotations }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
          build-args: |
            XOWEB=$XO_WEB
            XOSERVER=$XO_SERVER
          push: ${{ github.event_name == 'release' }}
      - name: Sign the published container images
        if: github.event_name == 'release'
        run: |
          cosign sign --yes --key env://COSIGN_PRIVATE_KEY "${TAGS}@${DIGEST}"
        env:
          TAGS: ${{ steps.meta.outputs.tags }}
          DIGEST: ${{ steps.build-and-push.outputs.digest }}
          COSIGN_PRIVATE_KEY: ${{ secrets.COSIGN_PRIVATE_KEY }}
          COSIGN_PASSWORD: ${{ secrets.COSIGN_PASSWORD }}

Error: Fail to load sigstore/cosign-installer/v2.0.0/action.yml

cosign-installer version: v2.0.0

When trying to use this version, the github action will sometimes fail on start up, and sometimes it'll pass the start up and proceed as expected.

Here's the code snippet of where I'm using the cosign installer:

Here is the error I'm getting:

Would this be an issue with v2.0.0? Would using the latest version fix these intermittent failures?
It's hard to know exactly how often it fails, but seems to be one in every 5 or so builds.

Consider versioning this action

Hey folks, what do you think about versioning this installer in the same way other GitHub actions do, like having a v1 branch rather than pointing to main?

TUF: invalid key

Description

Signing an image with cosign version v1.13.1 causes an error: TUF: invalid key. Seems like this is specifically has to do with cosign in github actions installed via cosign-installer.

Original Issue that was opened in cosign repo: sigstore/cosign#2390

Version

GitVersion:    v1.13.1
GitCommit:     d1c6336475b4be26bb7fb52d97f56ea0a1767f9f
GitTreeState:  clean
BuildDate:     2022-10-17T18:00:05Z
GoVersion:     go1.19.2
Compiler:      gc
Platform:      linux/amd64

Error

cosign sign --force myimage:test
Generating ephemeral keys...
Retrieving signed certificate...

        Note that there may be personally identifiable information associated with this signed artifact.
        This may include the email address associated with the account with which you authenticate.
        This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.
Successfully verified SCT...
WARNING: Image reference myimage:test uses a tag, not a digest, to identify the image to sign.

This can lead you to sign a different image than the intended one. Please use a
digest (example.com/ubuntu@sha256:abc123...) rather than tag
(example.com/ubuntu:latest) for the input to cosign. The ability to refer to
images by tag will be removed in a future release.
tlog entry created with index: 5992970
Pushing signature to: myimage:test
Generating SBOM attestation
Generating ephemeral keys...
Retrieving signed certificate...

        Note that there may be personally identifiable information associated with this signed artifact.
        This may include the email address associated with the account with which you authenticate.
        This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.
2022/10/27 17:34:27 error during command execution: getting key from Fulcio: verifying SCT: unable to initialize client, local cache may be corrupt: tuf: invalid key

Fix aarch64 runs

Description

There's a typo in the variable desired_cosign_filename in the ARM64 case which prevents the action to be executed in aarch64 runners.

Version

sudo breaks self-hosted runners

Description

After the addition of sudo about a week ago, this action non longer works on our self-hosted runners as the user running the runner does not have sudo privs by security design.

I would like a new optional input called use-sudo that can be set to true in case that their install-dir requires sudo privs.

Version

I'm using the latest version of cosign although this issue is not affected by the version of cosign

Failed to download 3.root.json

Description

Install cosign failed, https://github.com/karmada-io/karmada/actions/runs/5287357476/jobs/9568154587

Rerun github action and it's working,

Not sure it is a github action network problemm or installer problem.

...
      - name: Install Cosign
        uses: sigstore/[email protected]
        with:
          cosign-release: 'v1.13.1'
...

https://github.com/karmada-io/karmada/blob/5e14c5a3145c1089a0b56f4259477f6ee9cdf444/.github/workflows/dockerhub-latest-image.yml#L42-L45

INFO: Downloading bootstrap version 'v2.0.2' of cosign to verify version to be installed...
      https://github.com/sigstore/cosign/releases/download/v2.0.2/cosign-linux-amd64
INFO: Custom cosign version 'v1.13.1' requested
INFO: Downloading platform-specific version 'v1.13.1' of cosign...
      https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd64
INFO: Downloading detached signature for platform-specific 'v1.13.1' of cosign...
      https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd64.sig
INFO: Downloading cosign public key 'v1.13.1' of cosign...
    https://raw.githubusercontent.com/sigstore/cosign/v1.13.1/release/release-cosign.pub
WARNING: Skipping tlog verification is an insecure practice that lacks of transparency and auditability verification for the blob.
INFO: Using bootstrap cosign to verify signature of desired cosign version
Error: getting ctlog public keys: updating local metadata and targets: error updating to TUF remote mirror: tuf: failed to download 3.root.json: Get "https://tuf-repo-cdn.sigstore.dev/3.root.json": dial tcp: lookup tuf-repo-cdn.sigstore.dev on 127.0.0.53:53: read udp 127.0.0.1:42557->127.0.0.53:53: i/o timeout
remote status:{
	"mirror": "https://tuf-repo-cdn.sigstore.dev/",
	"metadata": {
		"root.json": {
			"version": 7,
			"len": 5404,
			"expiration": "04 Oct 23 13:08 UTC",
			"error": ""
		},
		"snapshot.json": {
			"version": 90,
			"len": 2303,
			"expiration": "03 Jul 23 16:03 UTC",
			"error": ""
		},
		"targets.json": {
			"version": 7,
			"len": 5[252](https://github.com/karmada-io/karmada/actions/runs/5287357476/jobs/9568154587#step:4:254),
			"expiration": "04 Oct 23 13:26 UTC",
			"error": ""
		},
		"timestamp.json": {
			"version": 90,
			"len": 721,
			"expiration": "26 Jun 23 16:03 UTC",
			"error": ""
		}
	}
}
main.go:74: error during command execution: getting ctlog public keys: updating local metadata and targets: error updating to TUF remote mirror: tuf: failed to download 3.root.json: Get "https://tuf-repo-cdn.sigstore.dev/3.root.json": dial tcp: lookup tuf-repo-cdn.sigstore.dev on 127.0.0.53:53: read udp 127.0.0.1:4[255](https://github.com/karmada-io/karmada/actions/runs/5287357476/jobs/9568154587#step:4:257)7->127.0.0.53:53: i/o timeout
remote status:{
	"mirror": "https://tuf-repo-cdn.sigstore.dev/",
	"metadata": {
		"root.json": {
			"version": 7,
			"len": 5404,
			"expiration": "04 Oct 23 13:08 UTC",
			"error": ""
		},
		"snapshot.json": {
			"version": 90,
			"len": 2[303](https://github.com/karmada-io/karmada/actions/runs/5287357476/jobs/9568154587#step:4:305),
			"expiration": "03 Jul 23 16:03 UTC",
			"error": ""
		},
		"targets.json": {
			"version": 7,
			"len": 5252,
			"expiration": "04 Oct 23 13:26 UTC",
			"error": ""
		},
		"timestamp.json": {
			"version": 90,
			"len": 721,
			"expiration": "26 Jun 23 16:03 UTC",
			"error": ""
		}
	}
}
Error: Process completed with exit code 1.

Cosign installer not working on windows

What went wrong?

Cosign can't be used in Windows after installing it with cosign-installer. It does nothing and it doesn't display an error.

How can we reproduce it?

Install cosign in github action using the installer, then try to run any cosign command. There will be no output or error message. You can see an example here, and you can see there is no message for cosign version in the github action.

What should the correct behavior be?

You should be able to run any cosign command and see the output as it is working in Linux

I think the problem is that the extension .exe is removed, and that's why cosign can't be executed. If we keep the extension it is working as expected

Security Policy violation Branch Protection

This issue was automatically created by Allstar.

Security Policy Violation
Dismiss stale reviews not configured for branch main
Block force push not configured for branch main

---

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Documented step to sign image with key is not working

Description

When setting up the action, using the key pair to generate the signtature of a docker image, the documented step is:

      - name: Sign image with a key
        run: |
          echo ${COSIGN_KEY} > /tmp/my_cosign.key && \
          cosign sign --key /tmp/my_cosign.key ${TAGS}
        env:
          TAGS: ${{ steps.docker_meta.outputs.tags }}
          COSIGN_KEY: ${{secrets.COSIGN_KEY}}
          COSIGN_PASSWORD: ${{secrets.COSIGN_PASSWORD}}

Now, when creating a repository secret containing the private key and trying to sign the image, the following error was returned:

Run echo $COSIGN_KEY > cosign.key && \
Error: signing [<some-image>[12](<action-link>)35220bf96fc87504ec76d37774]: getting signer: reading key: invalid pem block
main.go:46: error during command execution: signing [<some-image>]: getting signer: reading key: invalid pem block

What fixed the issue for me was to create a step before which writes the secret to a file and use that file within cosign sign:

      - name: Write cosign private key to file
        env:
         KEY: ${{ secrets.COSIGN_KEY }}
        shell: bash
        run: 'echo "$KEY" > cosign.key'

      - name: Sign image with a key
        run: |
          cosign sign --key cosign.key ${TAGS}
        env:
          TAGS: ${{ steps.docker_meta.outputs.tags }}
          COSIGN_PASSWORD: ${{secrets.COSIGN_PASSWORD}}

I'm not sure whether there's a better solution to fix this or a mistake I did, but it feels as if the documentation is wrong for the key example.

Support Windows and Mac installation

Description

Currently this action defaults to installing the linux-amd64 version of cosign, however GitHub Actions also provides Windows and Mac runners¹. The runner also works on ARM32 and ARM64 self-hosted runners². Windows, Mac, and ARM versions of cosign are already published³.

Footnotes

1. https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources ↩

2. https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#architectures ↩

3. https://github.com/sigstore/cosign/releases/latest ↩

Documented usage doesn't work when steps.docker_meta.outputs.tags contains multiple tag

Description

When steps.docker_meta.outputs.tags contains multiple tags, the suggested command

run: cosign sign --yes "${TAGS}@${DIGEST}"

doesn't work because it expands to:

cosign sign --yes tag-one
tag-two
tag-three@some-digest

This then results in an error.

Version

sigstore/[email protected]

Define permissions for actions

The cosign action doesn't provide the default permissions that are required. This increases the attack vector. https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/

It is recommended to define permissions.
https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

install cosign failed: error updating to TUF remote mirror: invalid key

Description

https://github.com/karmada-io/karmada/actions/runs/8355006523/job/22869302958

Run sigstore/[email protected]
  with:
    cosign-release: v1.13.1
    install-dir: $HOME/.cosign
    use-sudo: false
Run #!/bin/bash
INFO: Downloading bootstrap version 'v[2](https://github.com/karmada-io/karmada/actions/runs/8355006523/job/22869302958#step:4:2).1.1' of cosign to verify version to be installed...
      https://github.com/sigstore/cosign/releases/download/v2.1.1/cosign-linux-amd64
INFO: Custom cosign version 'v1.1[3](https://github.com/karmada-io/karmada/actions/runs/8355006523/job/22869302958#step:4:3).1' requested
INFO: Downloading platform-specific version 'v1.13.1' of cosign...
      https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd6[4](https://github.com/karmada-io/karmada/actions/runs/8355006523/job/22869302958#step:4:4)
INFO: Downloading detached signature for platform-specific 'v1.13.1' of cosign...
      https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd64.sig
INFO: Downloading cosign public key 'v1.13.1' of cosign...
    https://raw.githubusercontent.com/sigstore/cosign/v1.13.1/release/release-cosign.pub
INFO: Using bootstrap cosign to verify signature of desired cosign version
WARNING: Skipping tlog verification is an insecure practice that lacks of transparency and auditability verification for the blob.
Error: getting ctlog public keys: updating local metadata and targets: error updating to TUF remote mirror: invalid key
remote status:{
	"mirror": "https://tuf-repo-cdn.sigstore.dev",
	"metadata": {
		"root.json": {
			"version": 9,
			"len": 6766,
			"expiration": "12 Sep 24 06:[5](https://github.com/karmada-io/karmada/actions/runs/8355006523/job/22869302958#step:4:5)3 UTC",
			"error": ""
		},
		"snapshot.json": {
			"version": 132,
			"len": 2302,
			"expiration": "09 Apr 24 1[6](https://github.com/karmada-io/karmada/actions/runs/8355006523/job/22869302958#step:4:7):16 UTC",
			"error": ""
		},
		"targets.json": {
			"version": 9,
			"len": 5478,
			"expiration": "12 Sep 24 06:13 UTC",
			"error": ""
		},
		"timestamp.json": {
			"version": 169,
			"len": 723,
			"expiration": "26 Mar 24 16:16 UTC",
			"error": ""
		}
	}
}
main.go:74: error during command execution: getting ctlog public keys: updating local metadata and targets: error updating to TUF remote mirror: invalid key
remote status:{
	"mirror": "https://tuf-repo-cdn.sigstore.dev/",
	"metadata": {
		"root.json": {
			"version": 9,
			"len": 6766,
			"expiration": "12 Sep 24 06:53 UTC",
			"error": ""
		},
		"snapshot.json": {
			"version": 132,
			"len": 2[302](https://github.com/karmada-io/karmada/actions/runs/8355006523/job/22869302958#step:4:304),
			"expiration": "09 Apr 24 16:16 UTC",
			"error": ""
		},
		"targets.json": {
			"version": 9,
			"len": 5478,
			"expiration": "12 Sep 24 06:13 UTC",
			"error": ""
		},
		"timestamp.json": {
			"version": 169,
			"len": 723,
			"expiration": "26 Mar 24 16:16 UTC",
			"error": ""
		}
	}
}
Error: Process completed with exit code 1.

Version

  sigstore/[email protected]
  with:
    cosign-release: v1.13.1

OIDC Signing with Github now production ready?

Question

Hi 👋

The readme here says that OIDC signing from this action is not production ready yet.
The cosign docs page on OIDC signing states that OIDC signing is now not experimental anymore: https://docs.sigstore.dev/cosign/openid_signing/

Identity-based signing is now fully supported in Cosign.

Does this also mean that OIDC based signing from Github Actions is production ready?

Thank you 🙌

[feature] Support semver style versioning

Description

Thank you for this! We are using this project inside our workflow, and were using the project with no flags, which fetched our version at main. Due to the major version bump, our workflows broke because of the incompatible flags.

Would it be possible to support something like v2.0 that would fetch the latest patch version? This way we can recieve updated patches, but ensure not to break on any major version bump.

cc @laurentsimon @ianlewis