Immutable releases are now generally available on GitHub

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?

"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).

> The previous behavior is still available by the way, I'm not sure what you meant by "before".

I know, I was just wondering how it worked that needed this improvement.

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.

Thank you!