Pin all GitHub Actions to commit SHAs by silverwind · Pull Request #36971 · go-gitea/gitea

silverwind · 2026-03-24T02:40:27Z

Pin all third-party GitHub Actions to their current commit SHAs for supply chain security. The tag is preserved as a comment for readability and update tracking. All 20 unique actions across 12 workflow files have been pinned and verified via git ls-remote.

This PR was authored by Claude.

Pin all third-party GitHub Actions to their current commit SHAs for supply chain security. The tag is preserved as a comment for readability and update tracking. Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

lunny · 2026-03-24T04:13:14Z

Why commit SHAs is more safe?

bircni · 2026-03-24T06:14:11Z

Why commit SHAs is more safe?

You can move a tag but you cannot move a sha

wxiaoguang · 2026-03-24T07:30:22Z

I don't think it is a right approach to hard code the commit IDs in workflow file.

You can invent a wheel (or maybe there have been some wheels) to add a "workflow-lock.yaml" and store the branch/tag names & commit IDs in the lock file, and verify them. Manage them together.

silverwind · 2026-03-24T07:52:40Z

Why commit SHAs is more safe?

It protects from malicious tags. If such a tag is pushed to any branch on the action's repo it would compromise the action which can not happen with SHA pinning. Many repos are doing this, it's not exactly a new technique and recommended by GitHub.

Even with SHA tags, actions can be compromised through their dependencies, nothing can be done about that if a action chooses to unpin their dependencies.

workflow-lock.yaml

What's the difference from a SHA pin?

wxiaoguang · 2026-03-24T07:54:13Z

workflow-lock.yaml

What's the difference from a SHA pin?

Just like package.json and package-lock.json

You can still write - uses: actions/checkout@v6 in workflow yaml, it is clearer and easy to maintain.

silverwind · 2026-03-24T07:57:08Z

workflow-lock.yaml

What's the difference from a SHA pin?

Just like package.json and package-lock.json

You can still write - uses: actions/checkout@v6 in workflow yaml, it is clearer and easy to maintain.

So just a indirection. Yes such a script can be written and there's probably tools on npm for this.

BTW read up on attacks like https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise, many open source repos are getting compromised via actions nowadays, it's a popular attack vector.

wxiaoguang · 2026-03-24T07:59:02Z

workflow-lock.yaml

What's the difference from a SHA pin?

Just like package.json and package-lock.json
You can still write - uses: actions/checkout@v6 in workflow yaml, it is clearer and easy to maintain.

So just a indirection. Yes such a script can be written and there's probably tools on npm for this.

If there is no such tool, at least, I think the AI prompt should be committed together. Otherwise, people won't know how to upgrade from actions/checkout@v6 to actions/checkout@v7 correctly in the future.

Or, we maintain a "workflow-actions.yaml", and tell AI to use commit ID to update the workflow files

# workflow-actions.yaml
versions:
    actions/checkout: v7

Then AI will read workflow-actions.yaml and update all the workflow files.

I think this approach is pretty simple and clear.

TheFox0x7 · 2026-03-24T08:21:18Z

Btw renovate can do this and keep comment for the tag, but I can't exactly set a custom bot up without access to secrets. There's a global github one and @techknowlogick mentioned working on setting it up but not sure where that ended up.

Also to be clear since I looked at this for a long time. This is a theater in part. You're ensuring that the (broken package manager) will checkout the SHA for the action but there's nothing enforcing that the said action is immutable. There's no lock for the dependencies of the action so if anything that the said action uses gets compromised (be it another action, remote file it downloads or a JS package) that's going to run anyway despite the SHA pin.

silverwind · 2026-03-24T08:28:39Z

Yes, sha pinning with renovate will likely be the final solution. The format here is also exactly the one that renovate and other tools support.

wxiaoguang · 2026-03-24T08:36:09Z

Renovate can be the final answer. And maybe it can also update something like Update Nix flake #36943.

The question is: how should renovate be used?

Make renovate fully automatically update the dependencies
- The commit IDs can be locked (stay away from supply-chain attack)
- Attackers make a dependency get a new release: then still supply-chain attack?
Make renovate open a lot of PRs when a dependency gets a new version
- Will it make a lot of noises in the commit history?
- Who would really review the details of each change? If no review, it virtually equals to 1
Make renovate open one PR and combine all upgrades together regularly, e.g.: weekly?
- It virtually equals to 2: who would really review all the changes?
- Then virtually equal to 1 (better: stay away from supply-chain attack in one week)

silverwind · 2026-03-24T08:48:11Z

I would make renovate open a weekly or bi-weekly pr for maintenance updates with a possible fast-path for security updates. Definitly don't want 1 PR per update as that would be too noisy.

TheFox0x7 · 2026-03-24T09:01:18Z

Attackers make a dependency get a new release: then still supply-chain attack?

Renovate usually holds the dependancies for a bit before making a PR if it can - it's configurable though.
Personally I'd prefer smaller bundles instead of a huge change as it's easier to (if you wish) go through one change log than 30 of them.

btw if by "The commit IDs can be locked (stay away from supply-chain attack)" you mean actions part then it's not really protecting against that. It only protects from the action itself being changed but not against it's dependencies. It's a mess.

silverwind · 2026-03-24T09:05:34Z

Attackers make a dependency get a new release: then still supply-chain attack?

Renovate usually holds the dependancies for a bit before making a PR if it can - it's configurable though.

Yes that's "cooldown" and we have it configured for dependabot too:

gitea/.github/dependabot.yml

Lines 9 to 10 in c453d09

    
           cooldown: 
        
             default-days: 5

wxiaoguang · 2026-03-24T09:07:21Z

btw if by "The commit IDs can be locked (stay away from supply-chain attack)" you mean actions part then it's not really protecting against that. It only protects from the action itself being changed but not against it's dependencies. It's a mess.

Yep, dependency's dependency is another topic. That's why modern package managers have their own recursion lock (go.sum, package-lock.json, etc)

TheFox0x7 · 2026-03-24T09:09:18Z

Yeah... don't tell github. They haven't figured that out yet :)

Same approach as go-gitea#36971: pin every uses: ref to the full commit SHA with the version tag in a trailing comment. Adds the helpers:pinGitHubActionDigests preset so Renovate keeps future bumps in this format and converts any new tag-pinned actions automatically. DeterminateSystems/update-flake-lock previously tracked main; pinning to v28 matches what the action's release tagging promises and lets Renovate manage upgrades the same way as the others. Co-Authored-By: Claude (Opus 4.7) <noreply@anthropic.com>

silverwind · 2026-04-25T22:02:06Z

Superseded by #37050, which includes these SHA pins (in be25801) plus the Renovate config to keep them maintained.

DeterminateSystems/update-flake-lock was tracking main; pinned to v28 there as well. Renovate handles updates from a SHA pin natively, so the updates CLI alternative still works.

Comment by Claude Opus 4.7

Replaces Dependabot with Renovate. The new setup: - One PR per ecosystem (GitHub Actions, Go modules + Makefile go-tool pins, npm, Python via uv, Nix flake), opened weekly on Mondays with a 5-day release-age cooldown. Vulnerability PRs ship next-day via daily cron + Renovate's `vulnerabilityAlerts` schedule bypass. - All `uses:` action refs SHA-pinned with patch-level version comments (same format as #36971, which this supersedes); `helpers:pinGitHubActionDigests` keeps future bumps in that format. - `renovatebot/github-action` runtime image pinned via the upstream-recommended `RENOVATE_VERSION` env + magic comment + `customManagers:githubActionsVersions` preset, so Renovate keeps the pin updated. - Custom regex manager tracks the `*_PACKAGE ?= <import-path>@<version>` lines in `Makefile` (golangci-lint, swagger, actionlint, etc.) and groups them into the same Go PR via `matchDatasources: ["go"]`. - Post-upgrade tasks regenerate `assets/go-licenses.json` (`make tidy`) and the SVG sprite (`make svg`), gated by an env-level command allowlist. - Replaces the standalone `cron-flake-updater` workflow — Renovate's nix manager tracks `flake.nix` inputs and produces the same `flake.lock` bump PRs on the regular weekly schedule. - npm and gomod-replace pins live in `renovate.json5` only; `updates@17.16.3` reads them from there too, so the standalone `updates.config.ts` is gone and one source of truth covers both tools. Fixes: #33386 Signed-off-by: silverwind <me@silverwind.io> Signed-off-by: TheFox0x7 <thefox0x7@gmail.com> Co-authored-by: Claude (Opus 4.6) <noreply@anthropic.com> Co-authored-by: TheFox0x7 <thefox0x7@gmail.com> Co-authored-by: Nicolas <bircni@icloud.com> Co-authored-by: Giteabot <teabot@gitea.io>

Pin all GitHub Actions to commit SHAs

5dc374c

Pin all third-party GitHub Actions to their current commit SHAs for supply chain security. The tag is preserved as a comment for readability and update tracking. Co-Authored-By: Claude (Opus 4.6) <noreply@anthropic.com>

GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Mar 24, 2026

github-actions Bot added the modifies/internal label Mar 24, 2026

wxiaoguang marked this pull request as draft March 24, 2026 07:32

silverwind mentioned this pull request Mar 31, 2026

Integrate renovate bot for all dependency updates #37050

Merged

lunny removed the modifies/internal label Apr 19, 2026

silverwind closed this Apr 25, 2026

silverwind deleted the pin-github-actions-sha branch April 25, 2026 22:03

Uh oh!

Conversation

silverwind commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lunny commented Mar 24, 2026

Uh oh!

bircni commented Mar 24, 2026

Uh oh!

wxiaoguang commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

silverwind commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wxiaoguang commented Mar 24, 2026

Uh oh!

silverwind commented Mar 24, 2026

Uh oh!

wxiaoguang commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheFox0x7 commented Mar 24, 2026

Uh oh!

silverwind commented Mar 24, 2026

Uh oh!

wxiaoguang commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

silverwind commented Mar 24, 2026

Uh oh!

TheFox0x7 commented Mar 24, 2026

Uh oh!

silverwind commented Mar 24, 2026

Uh oh!

wxiaoguang commented Mar 24, 2026

Uh oh!

TheFox0x7 commented Mar 24, 2026

Uh oh!

silverwind commented Apr 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

silverwind commented Mar 24, 2026 •

edited

Loading

wxiaoguang commented Mar 24, 2026 •

edited

Loading

silverwind commented Mar 24, 2026 •

edited

Loading

wxiaoguang commented Mar 24, 2026 •

edited

Loading

wxiaoguang commented Mar 24, 2026 •

edited

Loading