For a user is there an easy way to see in the UI whether a given Github repo's releases are immutable?
Immutable releases are now generally available on GitHub
11–20 of 64 posts
Re: Immutable releases are now generally available on GitHub
#12I 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 actio…
I am seeing some docs now that suggest
> runs-on: [self-hosted, ...]
Must be added to run.yml to use custom / private action runners
I did not find these docs last time I looked and so my feature request may be already fulfilled
If anyone wants to chime in to say that `runs-on` can be relied on or not I would be grateful
Re: Immutable releases are now generally available on GitHub
#13I 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 willin…
If it happens, it would likely be fully integrated versioning in some LLM product.
Re: Immutable releases are now generally available on GitHub
#14Well I guess they're doing something at least. I kind of thought Github had moved to maintenance mode. Maybe we'll get stacked PRs one day?
Re: Immutable releases are now generally available on GitHub
#15My 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.
GitHub docs > Signing tags:
https://docs.github.com/en/authentication/managing-commit-si... :
> You can sign tags locally using GPG, SSH, or S/MIME
$ git tag -s MYTAG -m "Signed tag"
# Creates a signed tag
$ git tag -v MYTAG
# Verifies the signed tag
$ git commit -S -m 'Signed commit'Re: Immutable releases are now generally available on GitHub
#16For a user is there an easy way to see in the UI whether a given Github repo's releases are immutable?
> If a release is immutable, you will see " Immutable" below the title on the release page.
https://docs.github.com/en/code-security/supply-chain-securi...
Re: Immutable releases are now generally available on GitHub
#17Earlier quoted context omitted.
Git tags aren’t even really immutable, they’re treated as such but they’re not.
GitHub docs > Signing tags: https://docs.github.com/en/authentication/managing-commit-si... : > You can sign tags locally using GPG, SSH, or S/MIME $ git tag -s MYTAG -m "Signed tag" # Creates a signed tag $ git tag -v MYTAG # Verifies the signed tag Git book > 7.4 Git Tools - Signing Your Work: https://git-scm.com/book/ms/v2/Git-Tools-Signing-Your-Work : $ git commit -S -m 'Signed commit'
But you can still delete and recreate/sign the same tag again.
Re: Immutable releases are now generally available on GitHub
#18My 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.
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.
Re: Immutable releases are now generally available on GitHub
#19Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
I'd guess one MO is to delete a malicious package/url shortly after releasing it to prevent researchers from getting to it.