ci: pin vedantmgoyal9/winget-releaser to a SHA (v2) instead of @main - #4162
ci: pin vedantmgoyal9/winget-releaser to a SHA (v2) instead of @main#4162kobihikri wants to merge 1 commit into
Conversation
Sorry, something went wrong.
The winget publish job passes WINGET_TOKEN (a PAT) to a third-party action pinned to the mutable @main branch. Pin to the v2 release commit so a force-move/compromise of that branch can't run with the token.
|
We are we only doing this for this specific workflow, but not for all? Specifically, actions/checkout@v7 or similar are still moving targets. I guess the correct approach would be to add a zizmor workflow as done in my personal repositories, which enforces such aspects, but only updating one case when there are plenty more similar usages sounds incomplete/wrong. |
Sorry, something went wrong.
|
You're right, and thanks — that's fair. I pinned just this workflow because it was the only third-party action on a moving branch (@main) sitting next to a real secret (the WINGET_TOKEN), but you're correct that actions/checkout@v7 and others are moving too, and fixing one in isolation is lopsided. Your zizmor idea sounds like a much better, more durable fix — a linter that enforces this across every workflow rather than hand-pinning one at a time. I'm not deeply familiar with zizmor yet, though — would you have a reference or an example setup you'd recommend I follow? If it's welcome, I'm glad to open a PR adding a zizmor workflow, and either fold this winget pin into it or close this PR in favor of it — whichever you prefer. |
Sorry, something went wrong.
What this does
.github/workflows/winget.yml runs the third-party action vedantmgoyal9/winget-releaser@main in the release-publish job that holds secrets.WINGET_TOKEN (a PAT for winget-pkgs submissions). This pins it to the v2 release commit instead of the moving @main branch:
Why
@main resolves to whatever that branch's HEAD is at run time. If it were force-moved or compromised (the class of thing that happened with tj-actions/changed-files in 2025), the injected code would run with WINGET_TOKEN in scope. Every other third-party action in the repo's workflows is already tag-pinned — this was the one on a mutable branch. Pinning to the SHA of the v2 release keeps behavior identical while making updates deliberate.
One-line change. I confirmed 4ffc788 is the commit the v2 release tag points to.
Disclosure: I used an AI tool to help spot this and prepare the change; I verified the workflow and the pinned SHA myself and take responsibility for it.