←back to thread

151 points fastest963 | 1 comments | | HN request time: 0.241s | source
Show context
hoistbypetard ◴[] No.45772532[source]
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): >>45772557 #>>45772741 #>>45772761 #>>45773634 #>>45773953 #>>45774010 #
johnisgood ◴[] No.45772557[source]
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?

replies(3): >>45772706 #>>45772734 #>>45773693 #
danudey ◴[] No.45773693[source]
1. You could delete and re-create releases with the same name

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.

replies(1): >>45773732 #
1. johnisgood ◴[] No.45773732[source]
Thank you!