Feature request: enable immutable releases

[jayaddison]

GitHub has recently launched a feature to allow immutable releases; I think this could be helpful in cases where people want some level of assurance that they can fix and receive the same software/code/component when running processes that use version numbers over time: https://github.blog/changelog/2025-10-28-immutable-releases-are-now-generally-available/

I'd like to request for dorny/paths-filter to opt into that; as an alternative, I've pinned a version of it in a workflow file -- but today I learned that using pin-hashing prevents Dependabot Alerts from detecting vulnerable action versions in workflow files.

(I realise that second paragraph may seem tangential -- the reason I mention it is because I'd like assurance that both Dependabot Alerts could detect vulnerabilities in this action, and also that there would be assurance that deliberately-selected software versions would not change unexpectedly)

Thank you!

Refs:

• Documentation: limitations of Dependabot Alerts vulnerability detection: https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts#detection-of-insecure-dependencies
• Discussion: community feature request for Dependabot Alerts to detect vulnerable hash-pinned components: https://github.com/orgs/community/discussions/154189

[silverwind]

I don't think immutable releases work for actions because they only affect release assets not git content (which all actions are).

[jayaddison]

@silverwind

I don't think immutable releases work for actions because they only affect release assets not git content (which all actions are).

Good catch, that would be a problem if the feature only ensured that the asset files couldn't be modified. However: the blogpost does mention that the feature also offers immutability of tags.

In addition, although the immutable release feature can be disabled, tags that were created while immutable releases were enabled remain immutable.

So: if a release tag for a GitHub action is immutable (this is displayed in the web UI as a small lock logo/icon that appears alongside the release and tag) and you reference that using a fully-qualified label name (e.g. v5.0.0 instead of v5), then the content, and action behaviour, retrieved from that reference should not change.

I don't think that that would be incompatible with, for example, adding an expected SHA256 commit ID, or a similarly-strong content hash for the tree -- but it is an improvement in the level of tag assurance available on GitHub.

[silverwind]

Right, exact tag should work if that description is correct. What else works depends on how GitHub has implemented the feature exactly, e.g. whether force-push is at minimum disabled for any ancestor commit of the commits tagged by the protected tags. Also they'd need to deny tagging different commits with the same tag. I have my doubts whether this is bullet-proof.

[jayaddison]

As far as I'm aware, a single git tag can only be a pointer/reference to exactly one commit.

At a command-line level, I think that force pushes in git are only possible for named references -- typically branches or tags -- and not for individual commits. I do not know whether it is possible at a protocol-level to force-push one commit with another that has the same commit hash. I imagine that would be possible at the storage-level -- but it should also be extremely unlikely, provided that the commit has multiple parents and children -- for it to be possible to replace a single commit in such a way that the substitute is all four of: buildable/valid, passes tests, is a sensible and understandable modification in the context of the codebase at the time, and does not contain extraneous noise of the kind that could indicate an attempt to create a hash collision.

[silverwind]

Actually it says "tags are protected from being deleted or moved", so if GitHub has implemented this correctly, it should be immutable as far as the tag is concerned.

Still, the content of the action will not be immutable even with a static git tag because npm dependencies are mutable and actions has no lockfile and does not respect the ones from npm etc, see https://nesbitt.io/2025/12/06/github-actions-package-manager.html for details.

[jayaddison]

Yep - and worth noting that there are also some edge-cases around repositories that get renamed or otherwise relocated.

Even so: I think that human-readable names and versions are each useful -- they communicate some information about how the consumer learned of the software, and also when they did (especially in conjunction with version histories for both consumers and dependencies).

That's separate/orthogonal to the question of how to re-retrieve the identical source code for a given named, versioned software release in a repeatable way, and ensuring that the code landscape hasn't changed -- strong integrity hashing is good for that, and doesn't conflict with using human-readable addressing/referencing.

Some repositories might not want to opt-in to immutable releases, for various reasons -- and I think that other parts of the community have to accept that that's a possibility, and to fork or develop their own alternatives if they really feel the need to.

[saschabratton]

@jayaddison I am in favor of immutable releases, and exact version releases of this action are essentially immutable. While they are not technically immutable, they don't get changed retroactively.

With the exception of the floating version tags, e.g. v1, v2, v3, and v4. This is the standard pattern for GitHub Actions: the floating version tag is moved up to target the most recent minor/patch versions.

If enabling immutable releases allows us to make the exact version tags immutable (which are what get associated to releases) while keeping the floating version tags mutable, then we can enable immutable releases.

[saschabratton]

Based on my understanding and staff comments about it, we should be fine to enable immutable releases. See: https://github.com/orgs/community/discussions/171210#discussioncomment-14418724

[jayaddison]

@saschabratton

@jayaddison I am in favor of immutable releases, and exact version releases of this action are essentially immutable. While they are not technically immutable, they don't get changed retroactively.

Agreed; the benefit of immutable releases/tags is that should a repository become compromised, then people relying on those releases/tags will not receive different code/content. In other words: the source code and steps that they may have reviewed and agreed to previously cannot be modified at a later date.

With the exception of the floating version tags, e.g. v1, v2, v3, and v4. This is the standard pattern for GitHub Actions: the floating version tag is moved up to target the most recent minor/patch versions.

Yep - and, as I understand it, only released tags are made immutable. Tags that are pushed outside of the release workflow could continue to float/remap.

If enabling immutable releases allows us to make the exact version tags immutable (which are what get associated to releases) while keeping the floating version tags mutable, then we can enable immutable releases.

I believe it should do.

What I'm less sure about is whether:

• There is a way to require that some/all mutable/floating tags are only allowed to point to immutable/release tags (e.g. v3 would not be allowed to point to a commit SHA, or a mutable v3.5.0 tag).
• There is a way to require that the immutable/release tags pointed-to have the mutable/floating tag name as a prefix (e.g. v3 cannot be updated to point to an earlier v1.2.0 release tag, regardless of whether that release was immutable or not).