Would've made more sense to add a grey "Edited" to edited releases. Releases are not actually immutable, GitHub could change them. I don't know why you need to use sciency words to say "editing disabled".
Immutable releases are now generally available on GitHub
31–40 of 64 posts
Re: Immutable releases are now generally available on GitHub
#32Earlier quoted context omitted.
+1 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 t…
That is what ‘-1’ and the like are for.
Re: Immutable releases are now generally available on GitHub
#33My 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.
Yeah, how did it work before that it was not immutable?! > With immutable releases, assets and tags are protected from tampering after publication I really, really wonder how it worked before. Can anyone explain?
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.
Re: Immutable releases are now generally available on GitHub
#34Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
I think the reason here is to prevent deletion that cause upstream disruptions. See the reasoning in the PEP 763 (not adopted ) https://peps.python.org/pep-0763/
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)
Otherwise yes, leftpad/coverup risk is a thing
Re: Immutable releases are now generally available on GitHub
#35Earlier quoted context omitted.
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 t…
That is what ‘-1’ and the like are for.
Depending on the project, doing a re-release with an appended or updated version number might be a huge hassle. For a small, single-binary program run by an agile team it's pretty trivial to recall a release and publish a replacement, but for larger open-source projects with long, complex, release processes, paying customers, external docs, etc., spending an entire new day doing an entire new release to fix one typo in one word in one file in one artifact is less practical than just re-uploading the file and updating your SHA256SUMS.
Re: Immutable releases are now generally available on GitHub
#36Earlier quoted context omitted.
Yeah, how did it work before that it was not immutable?! > With immutable releases, assets and tags are protected from tampering after publication I really, really wonder how it worked before. Can anyone explain?
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 rebui…
Thank you!
Re: Immutable releases are now generally available on GitHub
#37Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
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.
Re: Immutable releases are now generally available on GitHub
#38My 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…
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.
Re: Immutable releases are now generally available on GitHub
#39My 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.
+1 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.
> 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.
Re: Immutable releases are now generally available on GitHub
#40Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
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…
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?