Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Immutable releases are now generally available on GitHub

github.blog

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Immutable releases are now generally available on GitHub

#41

Post by kbolino »

eviks wrote: post #28
kbolino wrote: post #27

Earlier quoted context omitted.

Deletion creates a hole. The hole can be filled by something else. This is a form of mutation. What you probably want instead is one-way revocation. You place a permanent marker that says "do not use this release because it is {broken, malicious, ...}".

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.

Re: Immutable releases are now generally available on GitHub

#42

Post by edflsafoiewq »

hoistbypetard wrote: post #2

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.

Mutable releases are used for continuous/nightly builds.

Re: Immutable releases are now generally available on GitHub

#45

Post by NoahZuniga »

shpx wrote: post #31

Would've made more sense to add a grey "Edited" to edited releases. Releases are not actually immutable, GitHub could change them. I don't know why you need to use sciency words to say "editing disabled".

They are immutable! The releases are signed with an attestation from a trusted third party that Github can't forge! Also these attestations are public and anyone can verify that the signing third party isn't misbehaving.

> Release attestations let you verify that an artifact is authentic and unchanged, even outside GitHub. Attestations use the Sigstore bundle format, so you can easily verify releases and assets using the GitHub CLI or integrate with any Sigstore-compatible tooling to automate policy enforcement in your CI/CD pipelines. For instructions on how to verify the integrity of a release, see our docs on verifying the integrity of a release.

They are using Sigstore, which is pretty standard in this space.

Re: Immutable releases are now generally available on GitHub

#46

Post by dare944 »

> When you enable immutable releases, the following protections are enforced: • Git tags cannot be moved or deleted; • Release assets cannot be modified or deleted

On the face of it, this seems like a non-starter. If a particular immutable release represents a danger to the consumer (extreme example: the software contains a bug that could result in physical injury) one must have the ability to retract that release so that no further consumers of the software could be affected by it. It makes sense that a retraction of an immutable release should not be reversible in such a way that the release could be recreated with different contents. But retractions must be possible, for both ethical and legal reasons.

I would also argue that its not sufficient to simply apply a blanket "deny all" access control to dangerous releases (assuming such a mechanism exists), as this does not adequately convey the deprecating nature of the change (and as a result, could mistakenly be reversed in the future). Ideally the retraction itself would be immutable such that once retracted the release is inaccessible forever.

Now, it may be that all this is supported by the new feature; I haven't had the chance to test it yet. But nothing in the documentation makes this clear one way or another.

Re: Immutable releases are now generally available on GitHub

#47

Post by TingPing »

jayknight wrote: post #17
westurner wrote: post #15

Earlier quoted context omitted.

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.

But GitHub has the option to prevent this. Just like branches.

Re: Immutable releases are now generally available on GitHub

#48

Post by weinzierl »

dare944 wrote: post #46

> When you enable immutable releases, the following protections are enforced: • Git tags cannot be moved or deleted; • Release assets cannot be modified or deleted On the face of it, this seems like a non-starter. If a particular immutable release represents a danger to the consumer (extreme example: the software contains a bug that could result in physical injury) one must have the ability to retract that release so…

I think there are compelling reasons to support:

1. Unremovable

2. Uninstallable while keeping the data available

3. Removing the release completely (while keeping an audit log that this happened)

1 is for use-cases where availability trumps security. I'd argue this should never be the case but at the same time it is how our world ticks by and large. Hard to take this away from people.

2 is for security, forensics and heritage but at the cost of availability. Uninstallable could mean to only offer the artifacts in an archive.

3 must always be possible as a last resort for illegal content that slipped through all previous safeguard layers.

Re: Immutable releases are now generally available on GitHub

#49

Post by westurner »

jayknight wrote: post #17
westurner wrote: post #15

Earlier quoted context omitted.

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.

Sigstore.dev supports revocation:

"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
If it is not possible to retract/revoke releases then, there again, the installer MUST verify against a signed list of revoked releases

Re: Immutable releases are now generally available on GitHub

#50

Post by cortesoft »

danudey wrote: post #35
cortesoft wrote: post #32

Earlier quoted context omitted.

That is what ‘-1’ and the like are for.

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 that case, it seems like immutable releases aren't what that project wants. You don't HAVE to enable immutable releases.

The ability to change a release is fundamentally incompatible with immutable releases, by definition. You can have one or the other, not both.

Post reply on HN