10 ms·

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 thi

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.

johnisgood 1y ago
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?
- a022311 1y ago
  "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".
  - johnisgood 1y ago
    > The previous behavior is still available by the way, I'm not sure what you meant by "before". I know, I was just wondering how it worked that needed this improvement.
- ItsHarper 1y ago
  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).
- danudey 1y ago
  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.
  - johnisgood 1y ago
    Thank you!
hk1337 1y ago
Git tags aren’t even really immutable, they’re treated as such but they’re not.
- westurner 1y ago
  GitHub docs > Signing tags: https://docs.github.com/en/authentication/managing-commit-signature-verification/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 https://git-scm.com/book/ms/v2/Git-Tools-Signing-Your-Work : $ git commit -S -m 'Signed commit'
  - jayknight 1y ago
    But you can still delete and recreate/sign the same tag again.
    - TingPing 1y ago
      But GitHub has the option to prevent this. Just like branches.
    - westurner 1y ago
      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-account-compromise-with-sigstore-ee299dca5144/ 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-sigstore-de1ed745f6fc/ 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/use-artifact-attestations/use-artifact-attestations#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
GuestFAUniverse 1y ago
+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.
- bluGill 1y ago
  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.
  - cortesoft 1y ago
    That is what ‘-1’ and the like are for.
    - danudey 1y ago
      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 one word in one file in one artifact is less practical than just re-uploading the file and updating your SHA256SUMS.
      - cortesoft 1y ago
        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.
danudey 1y ago
We've had a few issues in the past where a file wasn't updated during the release process, requiring us to re-publish one small change. It's not optimal, but given the nature of our release process being long and complex it's a lot easier to fix the asset in three minutes rather than spend an entire day re-building and re-publishing an entire release, updating our docs, etc. just because of one line in one file that wasn't updated correctly.
- hoistbypetard 1y ago
  I guess I'm just lucky, then, to have only dealt with release processes where it's no big deal to do a bump from 5.0.0 to 5.0.1 so I can address something like that. Some of them were long and complex, but they were scripted to the point where it was uniformly better to jump by a 0.0.1 than risk having two different releases with the exact same version # in the wild.
  - tuhgdetzhh 1y ago
    Yeah, depending on the size of the project you could end up having thousands of users downloading and installing 5.0.0 and then complaining.
edflsafoiewq 1y ago
Mutable releases are used for continuous/nightly builds.
- jsiepkes 1y ago
  In Java with Maven these have a special suffix, "-SNAPSHOT". So "1.0.0-SNAPSHOT". Releases, like "1.0.0" are immutable once released. I always thought that was a pretty sane model.
deleted 1y ago
[deleted]

johnisgood 1y ago

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?

a022311 1y ago
"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".
- johnisgood 1y ago
  > The previous behavior is still available by the way, I'm not sure what you meant by "before". I know, I was just wondering how it worked that needed this improvement.
ItsHarper 1y ago
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).
danudey 1y ago
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.
- johnisgood 1y ago
  Thank you!

hk1337 1y ago

Git tags aren’t even really immutable, they’re treated as such but they’re not.

westurner 1y ago
GitHub docs > Signing tags: https://docs.github.com/en/authentication/managing-commit-signature-verification/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 https://git-scm.com/book/ms/v2/Git-Tools-Signing-Your-Work : $ git commit -S -m 'Signed commit'
- jayknight 1y ago
  But you can still delete and recreate/sign the same tag again.
  - TingPing 1y ago
    But GitHub has the option to prevent this. Just like branches.
  - westurner 1y ago
    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-account-compromise-with-sigstore-ee299dca5144/ 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-sigstore-de1ed745f6fc/ 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/use-artifact-attestations/use-artifact-attestations#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

GuestFAUniverse 1y ago

+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.

bluGill 1y ago
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.
- cortesoft 1y ago
  That is what ‘-1’ and the like are for.
  - danudey 1y ago
    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 one word in one file in one artifact is less practical than just re-uploading the file and updating your SHA256SUMS.
    - cortesoft 1y ago
      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.

danudey 1y ago

We've had a few issues in the past where a file wasn't updated during the release process, requiring us to re-publish one small change. It's not optimal, but given the nature of our release process being long and complex it's a lot easier to fix the asset in three minutes rather than spend an entire day re-building and re-publishing an entire release, updating our docs, etc. just because of one line in one file that wasn't updated correctly.

hoistbypetard 1y ago
I guess I'm just lucky, then, to have only dealt with release processes where it's no big deal to do a bump from 5.0.0 to 5.0.1 so I can address something like that. Some of them were long and complex, but they were scripted to the point where it was uniformly better to jump by a 0.0.1 than risk having two different releases with the exact same version # in the wild.
- tuhgdetzhh 1y ago
  Yeah, depending on the size of the project you could end up having thousands of users downloading and installing 5.0.0 and then complaining.

edflsafoiewq 1y ago

Mutable releases are used for continuous/nightly builds.

jsiepkes 1y ago
In Java with Maven these have a special suffix, "-SNAPSHOT". So "1.0.0-SNAPSHOT". Releases, like "1.0.0" are immutable once released. I always thought that was a pretty sane model.

deleted 1y ago

[deleted]