Immutable releases are now generally available on GitHub
1–10 of 64 posts
Re: Immutable releases are now generally available on GitHub
#2My 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.
Re: Immutable releases are now generally available on GitHub
#3My 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?
Re: Immutable releases are now generally available on GitHub
#4I struggle to get excited about this sort of thing when the most essential functions of GitHub are falling apart. Reviewing PRs has somehow gotten even worse since the original react update.
I think the only thing that would fix this issue is for them to lose 20%+ of their customers to a competitor. Something very simple that can vacuum up the GHES migration archive and proceed as if it were 2018 again.
I'd be willing to completely sacrifice actions, project boards, copilot, et. al. if it meant I could have ultra fast views into code, issues and pulls. I really see no reason the PR view cannot be pre-rendered on the server when the branch is pushed each time. This should be an instantaneous response at review time. I don't care if it's 5 megabytes of diff - If my browser can handle the react slop, it can certainly handle a big chunk of static DOM.
Re: Immutable releases are now generally available on GitHub
#5My 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?
"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".
Re: Immutable releases are now generally available on GitHub
#6My 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?
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).
Re: Immutable releases are now generally available on GitHub
#7My 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.
Re: Immutable releases are now generally available on GitHub
#8My 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.
Re: Immutable releases are now generally available on GitHub
#9I am glad for this feature
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
Re: Immutable releases are now generally available on GitHub
#10Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?