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"?
> Revocation in Sigstore. A recent post on this blog notes that signatures alone don’t tell you whether to trust an artifact; for that, you need a verification policy. This verification policy is a much more natural place to handle revocation than the identity layer; see Don’t Panic for an example. This allows us to avoid the scalability problems of global revocation lists (see CRLite for a discussion of these issues). The mantra here is revoke artifacts, not keys.
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.
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.
i was likely too strong in saying nobody. Though they want immutabilty for theoretical purity reasons not for security which I'm sure is why github is doing this. Still it isn't bad toacknowledge them even if most don't care about their conterns.
> 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.
It's funny they call it "adding a new layer of supply chain security", when I reported it in August 2015 I got this answer:
> Thanks for the submission. We have reviewed your report and determined that it does not present a security risk. Tags and releases are not directly associated. The author lookup for a given release is done when that release is created and not upon subsequent updates. I can see how that could lead to some confusing behavior. I passed your observations on to our developers to see if we would want to change that behavior in the future. But, given that it does not present a security risk, it is not eligible for reward under the Bug Bounty program.
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.