Are versions like `v1` immutable?

[suzuki-shunsuke]

Hello, thank you for your great project!
I have a question.

I think the version like v1 is updated to the latest version of the same major version.
This means v1 is mutable.

https://github.com/actions/toolkit/blob/main/docs/action-versioning.md

But seems like the document says v1 is immutable.

Consumers of your action will then be able to specify that version to consume your action from the package, e.g.

• uses: your-name/your-action@v1
  Such packages will come with stronger security guarantees for consumers than existing git-based action resolution, such as:
  Tag immutability - it will not be possible to overwrite tags once published, ensuring versions of an action can't change once in use

What does it mean?

[dev-bio]

I would like this to be clarified as well.

[voxpelli]

The @v1 will become a request for the latest tag with major version 1.x.x – it's not a tag in itself. It says tags needs to follow semver, so tag needs to follow the x.y.z pattern. Compare to how npm, cargo, composer and similar work.

[dev-bio]

The @v1 will become a request for the latest tag with major version 1.x.x – it's not a tag in itself. It says tags needs to follow semver, so tag needs to follow the x.y.z pattern. Compare to how npm, cargo, composer and similar work.

If @1 isn't a tag, what would one call it? You essentially refer to a mutable major version. Consider a scenario where an attacker manages to compromise a repository, and deploy a new patch version, what stops a consumer from fetching a malicious action in their workflow?

I fear this whole thing will end up giving users a false sense of security.

[voxpelli]

It’s a version range selector in same way as npm, cargo, composer etc uses such? It selects a version from the published immutable versions?

[suzuki-shunsuke]

Thank you for your answer.
In that case, I think versions like v1 are mutable, not immutable.
So it's good to clarify this point so that users don't misunderstand this.

I think versions like v1 are useful as you don't need to update versions, but it harms security and stability of your workflows.
This is trade off, but I prefer semver like v1.0.0 over versions like v1.

About security, if an attacker compromises an action and creates a new version, workflows using versions like v1 are compromised immediately.
On the other hand, your workflow isn't compromised until you update actions if semver is used.
And if you update actions using Renovate, you can wait the update for a while using minimumReleaseAge, which is useful because probably you can notify the security incident before updating actions.

About stability, if the behaviour of an action is changed or a new version has a bug, your workflows may be broken immediately even though you don't change workflows. It confuses.

Anyway, thank you for your answer.

[justinmchase]

1 isn't a valid git tag is the problem.

My recommendation is to require specifically valid semantic versions for the tags such as 1.2.3 not v1 or v1.2.3 and then in the action syntax support valid semver ranges rather than binding to a tag.

Such as

- uses: example/action@^1.2.3

Given that we don't have lock files for actions if you want to lock your actions they should support an optional sha such as:

- users: example/action@^1.2.3#98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4

Then dependabot could either update the version if the latest is not in the range or just the sha if it is.