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?
Immutable releases are now generally available on GitHub
51–60 of 64 posts
Re: Immutable releases are now generally available on GitHub
#52My 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.
Git tags aren’t even really immutable, they’re treated as such but they’re not.
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"?
Re: Immutable releases are now generally available on GitHub
#53Uh, does this apply to the autogenerated source code artifacts? Those are famously not stable because they are generated on-demand with `git archive`. The value of this feature is really undermined if they don't also provide a source code download with a stable hash.
Re: Immutable releases are now generally available on GitHub
#54Earlier 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.
> 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.
Re: Immutable releases are now generally available on GitHub
#55Earlier quoted context omitted.
No, you can make the whole immutable, that is if a tag in an immutable repo was used and deleted, it can't be used again
An "immutable hole" just sounds like a "revocation marker" without an accompanying message, so I don't think we're really asking for different things, here. Nevertheless, ordinary tag deletion -- what git natively supports -- can't be supported directly.
The difference is the unavailability of content. For example, you attach the wrong binary and want to avoid confusion/mistaken downloads either manual or via tools that don't support your markers, in the most direct way - by deleting the binary from release.
But you can't fix it if you opted into the security benefits of no hidden mutation
Re: Immutable releases are now generally available on GitHub
#56My 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.
Mutable releases are used for continuous/nightly builds.
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.
Re: Immutable releases are now generally available on GitHub
#57Earlier quoted context omitted.
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.
Yeah, depending on the size of the project you could end up having thousands of users downloading and installing 5.0.0 and then complaining.
Re: Immutable releases are now generally available on GitHub
#58And yet I received an update from
uses: github/codeql-action/init@8a06050a8c0348fb4738f28e0cfbb6727cf054ce # v4.31.2
uses: github/codeql-action/init@0499de31b99561a6d14a36a5f662c2a54f91beee # v4.31.2
Re: Immutable releases are now generally available on GitHub
#59Just 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.
Re: Immutable releases are now generally available on GitHub
#60And yet I received an update from uses: github/codeql-action/init@8a06050a8c0348fb4738f28e0cfbb6727cf054ce # v4.31.2 to uses: github/codeql-action/init@0499de31b99561a6d14a36a5f662c2a54f91beee # v4.31.2 So someone must've moved the tag, even though that release is supposed to be immutable. https://github.com/github/codeql-action/releases
That release isn't immutable