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.
replies(6):
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.
> With immutable releases, assets and tags are protected from tampering after publication
I really, really wonder how it worked before. Can anyone explain?
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".
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.
> 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'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.
I know, I was just wondering how it worked that needed this improvement.
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.
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.
"Don’t Panic: A Playbook for Handling Account Compromise with Sigstore" (2022) https://blog.sigstore.dev/dont-panic-a-playbook-for-handling...
"Why you can’t use Sigstore without Sigstore" (2023) https://blog.sigstore.dev/why-you-cant-use-sigstore-without-... :
> 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.
Artifact Attestation > Verifying an artifact attestation for binaries: https://docs.github.com/en/actions/how-tos/secure-your-work/... :
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R orgname/reponame
The ability to change a release is fundamentally incompatible with immutable releases, by definition. You can have one or the other, not both.
I'm honestly a little surprised people seem to think they might be immutable - I guess maybe if people see "git" as "Actually Github"?
> 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.