Pin cache action version

[saibotk]

Description

This pins the cache action to its commit:
0400d5f644dc74513175e3cd8d07132dd4860809
Which is https://github.com/actions/cache/releases/tag/v4.2.4

Motivation and context

This allows people to enable the strict GitHub setting to only run pinned GitHub Actions. See https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization

How has this been tested?

This did not change anything really, but was tested internally in our workflows.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

PR checklist

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• I have added tests to cover my changes.

[jrfnl]

Ha! I was just about to open a PR for this, but luckily noticed this PR already being open.

Would be great if this could be released as a new 3.x version before updating actions/cache to v5.0.0 which was released today and will need to be released as a new major (as it means a change from Node 20 to Node 24).

@ramsey If it helps, the below is the commit message I'd written to argue the case for making/accepting this change.

Recently there has been more and more focus on securing GH Actions workflows - in part due to some incidents.

The problem with "unpinned" action runners is as follows:

• Tags are mutable, which means that a tag could point to a safe commit today, but to a malicious commit tomorrow.
  Note that GitHub is currently beta-testing a new "immutable releases" feature (= tags and release artifacts can not be changed anymore once the release is published), but whether that has much effect depends on the ecosystem of the packages using the feature.
  Aside from that, it will likely take years before all projects adopt immutable releases.
• Action runners often don't even point to a tag, but to a branch, making the used action runner a moving target.
  Note: this type of "floating major" for action runners used to be promoted as good practice when the ecosystem was "young". Insights have since changed.

While it is convenient to use "floating majors" of action runners, as this means you only need to update the workflows on a new major release of the action runner, the price is higher risk of malicious code being executed in workflows and this risk is exponential for the use of unpinned action runners in a package which is an action runner itself.

GitHub is now also actively promoting enforcing the use of pinned action runners via a new setting introduced a while back and currently, if that settings is turned on, this action runner will cause workflows to fail due to the unpinned use of the actions/cache action runner.

Dependabot can automatically submit PRs to update pinned action runners as long as the commit-hash pinned runner is followed by a comment listing the released version the commit is pointing to, though to be honest, I'm not entirely sure that works for action.yml files.

So this change may mean that you need to manually update the action.yml file more regularly.

A typical workflow for this can be:

1. Subscribe to watch "releases" for the actions/cache repo.
2. Install Pinact if not yet installed.
3. Whenever a new release has been tagged for actions/cache, review the release and then update the SHA in the action.yml file by running pinact run -u.

Future scope: something I have not got up and running yet, but might be worth experimenting with, is running pinact on a cronjob via GitHub Actions to alert on updates needed to the action.yml file and/or automatically create a PR.

Refs:

• https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions
• https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/

Note: I've not applied this change to the workflows in use by this repo itself as whether or not to do so should be a maintainer decision, what with the extra burden of more frequent Dependabot PRs.

But as the action.yml file is part of the published package, that's a different consideration and causes a security risk for other packages.

[ramsey]

I'm very sorry for just now seeing this. I need to review how my notifications work because I'm clearly not getting them (via email or otherwise).

Is it better to use the hash, or can you use the tag?

In other words, what's the difference between this:

uses: "actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809"

and this:

uses: "actions/cache@v4.2.4"

If there's no difference, I prefer to use the tag name.

What's the process for upgrading to a new version look like? This seems like undue burden on the upstream maintainers for having to update their version numbers to ensure downstream users remain secure. Isn't that why version "ranges" (i.e., @v4, @v4.2) exist? The downstream users should always get the latest version in the series, right? At least, that was my understanding.

I guess the problem here is that GitHub (or someone else) could release an action with a critical security flaw and no one is aware of it until after many have been compromised?

It seems like GitHub should implement lockfiles for actions, so downstream users can lock themselves to a specific version of all their action dependencies, but I digress...

I'll accept this. I'm just curious whether the actual hash is preferred over the specific tag name.

[ramsey]

One more question: since this PR was created, GitHub has released a number of other versions, including 5.0.0, and they are now at 5.0.3. Should I use the hash for the latest version instead, or should I stick with this hash for version 4.2.4?

[ramsey]

Tags are mutable, which means that a tag could point to a safe commit today, but to a malicious commit tomorrow.

Ah. @jrfnl, I see now why the hash is important and the tag name won't work.

[ramsey]

Thank you for contributing! 🎉

[jrfnl]

What's the process for upgrading to a new version look like? This seems like undue burden on the upstream maintainers for having to update their version numbers to ensure downstream users remain secure.

One more question: since this PR was created, GitHub has released a number of other versions, including 5.0.0, and they are now at 5.0.3. Should I use the hash for the latest version instead, or should I stick with this hash for version 4.2.4?

Updates will be pulled by Dependabot, as usual.

For this to work, the # v4.2.4 comment is required as Dependabot uses that to check for new releases.

This also means that Dependabot updates will now likely come with a much higher frequency.
Depending on how many repos you manage, this can be quite a burden, so one of the things I typically combine a PR to pin action runners with, is a commit to change the Dependabot frequency for the github-actions ecosystem from the default weekly, to a cron job which will check once or twice a month.

That makes it easier to manage the flood of PRs.

Alternatively, you can locally use the pinact tool to update the workflow (or to set up PRs similar to this one for other repos).

It seems like GitHub should implement lockfiles for actions,

💯 (and I happen to know they are working on something like this is in the background)

Basically, GHA is a system which was set up for use with private repos and then made public. It was never designed with security in mind and they are now scrambling to catch up (and giving maintainers a shitload of work to secure workflows in the mean time).

@ramsey Hope this explains things a little more!

[jrfnl]

Dependabot can automatically submit PRs to update pinned action runners as long as the commit-hash pinned runner is followed by a comment listing the released version the commit is pointing to, though to be honest, I'm not entirely sure that works for action.yml files.

@ramsey Now this PR has been merged and knowing that the action runner is out of date.... you should be able to manually trigger a Dependabot run on the https://github.com/ramsey/composer-install/network/updates page. If that creates a PR to update to the v5 major for this action runner, then it would confirm that Dependabot also handles action.yml files.

[ramsey]

@jrfnl Looks like it works:

https://github.com/ramsey/composer-install/pull/278/changes

[Slamdunk]

Tags are mutable, which means that a tag could point to a safe commit today, but to a malicious commit tomorrow.

Ah. @jrfnl, I see now why the hash is important and the tag name won't work.

Hashes are a good choice, but once Immutable Releases are enabled in that repo I would prefer to see a tag pin instead.