Any objections against turning on immutable releases for Git for Windows?

[dscho]

As per https://github.blog/changelog/2025-10-28-immutable-releases-are-now-generally-available/, there is now an option to opt into immutable releases. This would provide a little bit of confidence in Git for Windows, as releases could not be tampered with after being released by the automation.

Does anyone see any downside?

Side note: We cannot do this org-wide because https://github.com/git-for-windows/git-sdk-64/releases/tag/ci-artifacts needs to stay a "rolling release", i.e. it will be modified frequently, intentionally so. But we could consider opting other repositories into immutable releases, e.g. the Actions (like setup-git-for-windows-sdk) or https://github.com/git-for-windows/pacman-repo or https://github.com/git-for-windows/git-snapshots.

I am looking in particular for feedback from my friendly co-maintainers, @rimrul and @mjcheetham.

[rimrul]

This would provide a little bit of confidence in Git for Windows, as releases could not be tampered with after being released by the automation.

Presumably this would already prevent modifications during the automation. We need to keep in mind that for https://github.com/git-for-windows/git
we create a release and then update it twice in automation.
https://github.com/git-for-windows/git-for-windows-automation/blob/main/.github/actions/github-release/action.yml

[dscho]

we create it in draft mode

Here, we call createRelease() with 8 parameters, the 9th (draft) is therefore undefined, which is interpreted as true.

Side note: The best practice these days seems to be to convert the positional parameters to an object with named parameters, that would make this clearer, I guess.

[rimrul]

I guess making the draft immutable would defeat the purpose of a draft. We do convert from draft to non-draft in the first update though and then update again to create a discussion. That probably continues to work, but we should test that.

[dscho]

That's a good point! We likely need to revert git-for-windows/git-for-windows-automation@b59f512.

[dscho]

See git-for-windows/git-for-windows-automation#142

[dscho]

I flipped the switch for git-for-windows/git (after releasing -rc0, I had planned to flip it before, but forgot...)

[derrickstolee]

I'll just give an extra 👍 to making the actions be immutable releases, too. That plugs a big security hole whenever you refer to an action by tag and not commit hash.

[dscho]

I'll just give an extra 👍 to making the actions be immutable releases, too.

For the record, these Actions do not even have any non-source assets, and therefore do not need any careful "first create in draft mode, then upload assets, then mark as non-draft" handling:

• get-azure-pipelines-artifact
• setup-git-for-windows-sdk
• rss-to-issues

So I flipped the switch for them.

For pacman-repo, I notice that the releases are created in draft mode, then the assets are uploaded to that draft release, and finally the release is marked as non-draft. In other words, it follows the recommended pattern.

So I flipped the switch there, too.

For git-snapshots, we use gh release create, specifying the assets to upload as command-line arguments. According to this comment in GitHub CLI (ignore the funny way the backtick is specified, Go has certain limitations by design that Go's architects are seemingly fine with):

When using the create command to attach assets to a release, separate API calls are made to create the release as a draft, upload the assets, and then publish the release. Immutability protections will be enforced ONLY after the release is published.

And indeed, the code agrees: it sets draftWhileUploading when assets are specified for non-draft releases, then forces draft mode on, then creates the release (in draft mode), then uploads the assets, and finally publishes the release (explicitly turning off draft mode).

So I flipped the switch there, too.

[dscho]

Okay, I went ahead and turned on immutable releases where applicable:

• git (the main repository)
• get-azure-pipelines-artifact (Action, no binary assets)
• setup-git-for-windows-sdk (Action, no binary assets)
• rss-to-issues (Action, no binary assets)
• git-snapshots (snapshot builds)
• pacman-repo (the repository containing the packages used in Git for Windows' SDK)

These repositories do have releases, but they are "rolling releases", i.e. they cannot be immutable:

• git-sdk-arm64
• git-sdk-64
• git-sdk-32

These have releases, but I skipped them:

• build-extra (only has the Git for Windows SDK)
• MSYS2-packages (only test releases)
• MINGW-packages (only test releases)
• msys2-runtime (only test releases)

These repositories have no releases, nor are there any plans on adding any:

• gfw-helper-github-app
• git-for-windows-automation
• track-website-changes
• git-for-windows.github.io
• 7-Zip
• WinToast
• busybox-w32