My instant reaction was: "Wait?! They weren't immutable before?"
I'm glad they're doing this, and it's an unpleasant surprise that they didn't already work this way. I don't understand why they allow mutable releases.
We've had a few issues in the past where a file wasn't updated during the release process, requiring us to re-publish one small change. It's not optimal, but given the nature of our release process being long and complex it's a lot easier to fix the asset in three minutes rather than spend an entire day re-building and re-publishing an entire release, updating our docs, etc. just because of one line in one file that wasn't updated correctly.
I guess I'm just lucky, then, to have only dealt with release processes where it's no big deal to do a bump from 5.0.0 to 5.0.1 so I can address something like that. Some of them were long and complex, but they were scripted to the point where it was uniformly better to jump by a 0.0.1 than risk having two different releases with the exact same version # in the wild.
Any "given" name/ID (IE anything but the full hash) in a distributed VCS has to be mutable - without some single central arbiter of truth it's simply impossible.
I'm honestly a little surprised people seem to think they might be immutable - I guess maybe if people see "git" as "Actually Github"?
1. You could delete and re-create releases with the same name
2. You could delete and re-create tags with the same name, even if a release was pointing to that tag already
3. You could delete and re-create an asset that was uploaded to a release without doing any of the above.
By and large none of this is a problem on the surface, but you could imagine someone who gains access to a project's release credentials rebuilding a binary with a backdoor and replacing the existing, published version in the release with their new version after the fact.
An immutable release means that you could only inject that code during the release process by injecting the backdoor into the code itself, and since Github allows you to prevent code from entering a branch except through an approved PR and signed commits, it's possible to make that much more difficult or impractical.
"Before", it was trivial to move or delete tags and edit release assets. The only stable identifier available was the commit hash.
Immutable releases now enable permanently locking tags and releases to make supply chain attacks harder to affect users who are using release assets from before an attack occurred.
The previous behavior is still available by the way, I'm not sure what you meant by "before".
Anyone with the appropriate perms could replace binaries uploaded to the release at will. You could also change which commit a release's tag pointed to by deleting and re-creating the release (the link would end up the same since it just references the tag).
In Java with Maven these have a special suffix, "-SNAPSHOT". So "1.0.0-SNAPSHOT". Releases, like "1.0.0" are immutable once released. I always thought that was a pretty sane model.
Nobody thought about mutable releases being utterly bad _before_?
Baffles me...
As bad as hardware vendors selling products with different chips inside as the same model (hello Cisco -- at least in former times; hello HP, formerly selling at least three different, _incompatible_ laptop power supplies with the same label).
Mutability: surprise, surprise, I'm not what you expected! -- maybe one of IT's worst ideas.
Once in a while someone makes a mistake and it is helpful to just fix it.
I've done it myself, create a release, upload it, download to a different machine and discover it doesn't work there, so fix and retest. Only after all those steps do I hit send on the release announcement. This is a useful workflow (particularly the first time you release when you don't even know what you are doing).
So long as nobody abuses that mutable releases are a great thing. However a tiny minority of people are not trustworthy and so we are forced to take away a great things because of that minority.
> Nobody thought about mutable releases being utterly bad _before_? Baffles me...
Some of us been requesting it as a feature since 2016, just because it wasn't implemented until now doesn't mean even people inside GitHub hasn't thought about it.
> When you enable immutable releases, the following protections are enforced: • Git tags cannot be moved or deleted; • Release assets cannot be modified or deleted
On the face of it, this seems like a non-starter. If a particular immutable release represents a danger to the consumer (extreme example: the software contains a bug that could result in physical injury) one must have the ability to retract that release so that no further consumers of the software could be affected by it. It makes sense that a retraction of an immutable release should not be reversible in such a way that the release could be recreated with different contents. But retractions must be possible, for both ethical and legal reasons.
I would also argue that its not sufficient to simply apply a blanket "deny all" access control to dangerous releases (assuming such a mechanism exists), as this does not adequately convey the deprecating nature of the change (and as a result, could mistakenly be reversed in the future). Ideally the retraction itself would be immutable such that once retracted the release is inaccessible forever.
Now, it may be that all this is supported by the new feature; I haven't had the chance to test it yet. But nothing in the documentation makes this clear one way or another.
3. Removing the release completely (while keeping an audit log that this happened)
1 is for use-cases where availability trumps security. I'd argue this should never be the case but at the same time it is how our world ticks by and large. Hard to take this away from people.
2 is for security, forensics and heritage but at the cost of availability. Uninstallable could mean to only offer the artifacts in an archive.
3 must always be possible as a last resort for illegal content that slipped through all previous safeguard layers.
Your note on 3 brings up a good point: I'm sure that if there's a DMCA takedown notice or somesuch that GitHub will in fact delete your "immutable" release which "can't be deleted".
If I have anyone's attention there is something related I would like to see
Please add a small thing which users can look for on the public: repo/actions page
This small thing should let users know the action was run by github like is default and not run on a custom / private action runner
The private action runner feature makes sense but many projects tell users to look to the github action history to trust that tests A, B, C passed. If the github action ran on a private action runner then you really cannot trust that what is in e.g. run.yml actually ran
The attestation feature can be used to prove that an action was run by github and not by private / custom but users need to install the github cli to validate attestations and this is a heavy ask when I think an addition icon on repo/actions page or a diff icon color will do better
1. A release turns out to contain an exploitable bug
2. A release is published to fix the bug
3. Someone malicious with access deletes the release
4. Everyone downloading the "latest" version gets the exploitable version until the developers notice and re-publish again
I think about tools used in CI systems that are often re-downloaded in each run, like `helm` or `kubectl` or `crane` for example; if they're pinning a previous version they stay exploitable, and if they're downloading the 'latest' from Github then this switcheroo keeps them exploitable. Given that a lot of emergency security releases come with disclosure ("this is being released to resolve CVE-2025-12345") another 12 hours of exploitability can be critical.
Thanks, interesting scenario, but if you have access to releases like that how is this easier vs just publishing a release with an exploit and getting the same X hours before you're discovered?
Deletion creates a hole. The hole can be filled by something else. This is a form of mutation.
What you probably want instead is one-way revocation. You place a permanent marker that says "do not use this release because it is {broken, malicious, ...}".
Strange they haven't identified negative security implications: if the owner notices the hack he can delete the malicious release before the central authority, so this would limit the blast radius (think there was a recent such issue with npm where there was a delay between discovery (by the author) and removal)
This seems too strong to me, especially the prohibition on deletion. Why couldn't they have instead just showed a record of modifications to releases, and/or embedded a hash of the contents in the URL to them?
Just remember the only truly immutable release is one signed by a key the host does not have access to, or one where you pin a hash locally at the point of consumption.
Microsoft does not have strict third party code review policies internally, has been hit with supply chain attacks before, and will be hit again. Consider this a nice to have feature, but give it zero trust.
As I'm working on a signing scheme for release authentication, this is a welcome news.
To alleviate the issue of mutable releases I had set up a mirror of releases checksums to be able to detect releases alterations. This is not needed anymore for immutable releases.
And automatically publishing checking of releases artifacts is also a good recent change by GH: in that project mentioned above I have developed a cli downloader checking the checksums of the downloaded file [1], but to be useful, it required the project to publish checksums, and the project to be mirrored. Now both of these requirements are dropped and the tool is readily useful for all GitHub immutable releases.
Readit News
I'm glad they're doing this, and it's an unpleasant surprise that they didn't already work this way. I don't understand why they allow mutable releases.
I'm honestly a little surprised people seem to think they might be immutable - I guess maybe if people see "git" as "Actually Github"?
> You can sign tags locally using GPG, SSH, or S/MIME
Git book > 7.4 Git Tools - Signing Your Work: https://git-scm.com/book/ms/v2/Git-Tools-Signing-Your-Work :> With immutable releases, assets and tags are protected from tampering after publication
I really, really wonder how it worked before. Can anyone explain?
2. You could delete and re-create tags with the same name, even if a release was pointing to that tag already
3. You could delete and re-create an asset that was uploaded to a release without doing any of the above.
By and large none of this is a problem on the surface, but you could imagine someone who gains access to a project's release credentials rebuilding a binary with a backdoor and replacing the existing, published version in the release with their new version after the fact.
An immutable release means that you could only inject that code during the release process by injecting the backdoor into the code itself, and since Github allows you to prevent code from entering a branch except through an approved PR and signed commits, it's possible to make that much more difficult or impractical.
Immutable releases now enable permanently locking tags and releases to make supply chain attacks harder to affect users who are using release assets from before an attack occurred.
The previous behavior is still available by the way, I'm not sure what you meant by "before".
Deleted Comment
Nobody thought about mutable releases being utterly bad _before_? Baffles me...
As bad as hardware vendors selling products with different chips inside as the same model (hello Cisco -- at least in former times; hello HP, formerly selling at least three different, _incompatible_ laptop power supplies with the same label).
Mutability: surprise, surprise, I'm not what you expected! -- maybe one of IT's worst ideas.
I've done it myself, create a release, upload it, download to a different machine and discover it doesn't work there, so fix and retest. Only after all those steps do I hit send on the release announcement. This is a useful workflow (particularly the first time you release when you don't even know what you are doing).
So long as nobody abuses that mutable releases are a great thing. However a tiny minority of people are not trustworthy and so we are forced to take away a great things because of that minority.
Some of us been requesting it as a feature since 2016, just because it wasn't implemented until now doesn't mean even people inside GitHub hasn't thought about it.
On the face of it, this seems like a non-starter. If a particular immutable release represents a danger to the consumer (extreme example: the software contains a bug that could result in physical injury) one must have the ability to retract that release so that no further consumers of the software could be affected by it. It makes sense that a retraction of an immutable release should not be reversible in such a way that the release could be recreated with different contents. But retractions must be possible, for both ethical and legal reasons.
I would also argue that its not sufficient to simply apply a blanket "deny all" access control to dangerous releases (assuming such a mechanism exists), as this does not adequately convey the deprecating nature of the change (and as a result, could mistakenly be reversed in the future). Ideally the retraction itself would be immutable such that once retracted the release is inaccessible forever.
Now, it may be that all this is supported by the new feature; I haven't had the chance to test it yet. But nothing in the documentation makes this clear one way or another.
1. Unremovable
2. Uninstallable while keeping the data available
3. Removing the release completely (while keeping an audit log that this happened)
1 is for use-cases where availability trumps security. I'd argue this should never be the case but at the same time it is how our world ticks by and large. Hard to take this away from people.
2 is for security, forensics and heritage but at the cost of availability. Uninstallable could mean to only offer the artifacts in an archive.
3 must always be possible as a last resort for illegal content that slipped through all previous safeguard layers.
If I have anyone's attention there is something related I would like to see
Please add a small thing which users can look for on the public: repo/actions page
This small thing should let users know the action was run by github like is default and not run on a custom / private action runner
The private action runner feature makes sense but many projects tell users to look to the github action history to trust that tests A, B, C passed. If the github action ran on a private action runner then you really cannot trust that what is in e.g. run.yml actually ran
The attestation feature can be used to prove that an action was run by github and not by private / custom but users need to install the github cli to validate attestations and this is a heavy ask when I think an addition icon on repo/actions page or a diff icon color will do better
> runs-on: [self-hosted, ...]
Must be added to run.yml to use custom / private action runners
I did not find these docs last time I looked and so my feature request may be already fulfilled
If anyone wants to chime in to say that `runs-on` can be relied on or not I would be grateful
2. A release is published to fix the bug
3. Someone malicious with access deletes the release
4. Everyone downloading the "latest" version gets the exploitable version until the developers notice and re-publish again
I think about tools used in CI systems that are often re-downloaded in each run, like `helm` or `kubectl` or `crane` for example; if they're pinning a previous version they stay exploitable, and if they're downloading the 'latest' from Github then this switcheroo keeps them exploitable. Given that a lot of emergency security releases come with disclosure ("this is being released to resolve CVE-2025-12345") another 12 hours of exploitability can be critical.
What you probably want instead is one-way revocation. You place a permanent marker that says "do not use this release because it is {broken, malicious, ...}".
See the reasoning in the PEP 763 (not adopted )
https://peps.python.org/pep-0763/
Otherwise yes, leftpad/coverup risk is a thing
Microsoft does not have strict third party code review policies internally, has been hit with supply chain attacks before, and will be hit again. Consider this a nice to have feature, but give it zero trust.
To alleviate the issue of mutable releases I had set up a mirror of releases checksums to be able to detect releases alterations. This is not needed anymore for immutable releases.
And automatically publishing checking of releases artifacts is also a good recent change by GH: in that project mentioned above I have developed a cli downloader checking the checksums of the downloaded file [1], but to be useful, it required the project to publish checksums, and the project to be mirrored. Now both of these requirements are dropped and the tool is readily useful for all GitHub immutable releases.
1: https://github.com/asfaload/asfald/
https://docs.github.com/en/code-security/supply-chain-securi...