cosing-installer default is to make updating cosign difficult

[jku]

Problem

Most cosign users run an unsupported old version (at least 65% of cosign clients that made a request to Rekor last week were < 2.6.0)

Potential root causes in cosign-installer

Obviously some people just don't upgrade their software and some workflows are just abandoned but my hunch is that cosign-installer does a few things that may be negatively affecting this statistic.

Widespread use of cosign-release argument

The first example in README looks like this

uses: sigstore/cosign-installer@v4.0.0
with:
  cosign-release: 'v3.0.3' # optional

• I believe this has lead to widespread use of this pattern (including the cosign-release argument in the workflow)
• this means anyone using dependabot will get updates for cosign-installer and may think they're covered... but may in fact be running very old cosign

cosign-installer hard codes a cosign version but does not follow cosign release schedule

The users who do not set cosign-release will get a default value that is hard-coded in the action: This seems fine as a new release of cosign-installer typically updates that default value.

Unfortunately cosign releases almost invariably happen without a corresponding cosign-installer release. Current cosign-installer by default installs a cosign version that has a vulnerability in it.

Potential fixes

• Start breaking cosign-release gradually. This could be done in many ways but a straw man suggestion:
  • Document that cosign-release should not be used in normal use: One version of cosign-installer will always use the same cosign version so setting cosign-release does not improve reproducibility
  • Hard code a "supported releases list" in the installer:
    • accept only these versions and higher as cosign-release value. Current list could be ["2.6.2", "3.0.5"]
    • Make sure the error message makes it clear most users should not be using the cosign-release argument at all
  • (Maybe) Add an argument use-unsupported-cosign-release so users who really want to run 2.2.0 can override this behaviour
• cosign release must lead to a cosign-installer release soon after -- or alternatively cosign-installer must stop hard coding the cosign version
  • New release should update the default cosign version and the "supported releases list" if that is added
  • Some automation in this repo should be able to at least open an issue if not a PR

[jku]

Hard code a "supported releases list" in the installer

This actually already exists: the minimum version is currently 2.0.0

[jku]

Document that cosign-release should not be used in normal use: One version of cosign-installer will always use the same cosign version so setting cosign-release does not improve reproducibility

The linked PR mostly handles this part.

[loosebazooka]

As part of accelerating the last rekorv2 tasks -- and to close out this task, a summary with minor edits of what was proposed above

release a major version (v5.0.0) update with

• no cosign-release; replaced by another parameter cosign-version (yaml errors at validation time)
• cosign-version has minimums defined (2.6.2, 3.0.5)
• I don't think we should let people use old version of cosign using this action

add infra to

• check cosign latest release and plugs it into this build and triggering some sort of "new release" issue

clean up docs

• get people to stop using cosign-release/cosign-version by default. Updating the minimums breaks those at runtime rather that action verification time.

[loosebazooka]

@cmurphy @steiza any thoughts on this issue?

[steiza]

I have not given a lot of thought to cosign-installer.

Releasing a major version (v5) with breaking changes sounds okay to me, especially if we put in the release notes instructions on what changes to make to upgrade.

no cosign-release; replaced by another parameter cosign-version

Maybe this should be cosign-major-version, and the two acceptable values (for now) are 2 or 3?

It seems like we want to get out of the business of tracking minor and patch versions in cosign-installer. It could look up what releases are available in sigstore/cosign and grab the latest v2 (or v3) release as needed. Then we also wouldn't need infra to update cosign-installer every time we have a Cosign patch release.

[jku]

It could look up what releases are available in sigstore/cosign and grab the latest v2 (or v3) release as needed

This does have a disadvantage: we would change the signing/verifying software without the user really knowing about it. I'm not saying it's the wrong choice but it's unusual (not how actions typically work) and has a bit of a bad-supply-chain smell

[steiza]

This does have a disadvantage: we would change the signing/verifying software without the user really knowing about it. I'm not saying it's the wrong choice but it's unusual (not how actions typically work) and has a bit of a bad-supply-chain smell

That's fair!

[cmurphy]

I'm definitely in favor of

add infra to check cosign latest release and plugs it into this build and triggering some sort of "new release" issue
clean up docs - get people to stop using cosign-release/cosign-version by default

I'm not really clear on what value thecosign-version parameter brings over just hardcoding the version.

It's sounding to me like the crux of the issue is we have a cosign-installer action that automatically gets updated by dependabot but a cosign-release argument that gets no automatic updates. Why not just make it simple and tie the cosign-installer version to the cosign version and get rid of cosign-release/cosign-version altogether?