Proposal: Allow opting out of cache ref restrictions

[joshmgross]

As described in Restrictions for accessing a cache, caches are tied to a git ref (branch or tag). This level of isolation is critical to the security model for caching - without it caches would be a shared resource across all Actions workflow runs in a repository. This could be exploited to access trusted resources or secrets in trusted workflow runs by poisoning a cache in an untrusted context (such as workflow run from a fork pull request or on an unprotected branch).

Depending on their own trust model, not all users need this level of protection and it introduces friction that pushes users towards external solutions. Additionally, some events such as the merge_group don't work well with the branch isolation model due to usage of temporary refs.

This is not a simple change nor is it something we'd change within the cache action itself as these permissions are built into the Actions JWT token used to authenticate with internal Actions APIs. Filing this discussion is not a commitment that we will add this feature, but I'd like to gather user feedback into a single place and understand the use cases better.

Open Questions

1. Should this be an "all or nothing" feature or allow granularly defining when branch restrictions should be used?
2. Is there a legitimate scenario where this would be useful in a public repository and safe to use?
3. If permissions in a workflow worked with caching, how does impact the need for branch restrictions?
4. Can we safely allow this to be configurable by the action within a workflow or does it require being a repository setting?

Related Issues

• community/actions-feedback-migrations#79
• community/actions-feedback-migrations#319
• #1371
• #1496
• #1537
• #1543

[aminya]

Filing this discussion is not a commitment that we will add this feature, but I'd like to gather user feedback into a single place and understand the use cases better.

I don't think there is any gap in the user feedback. There have been hundreds of requests and comments in the linked issues over the years. So, it's a no-brainer that the users need this.

I'll repeat my comment just in case:

This cache miss across different branches is creating anti-patterns in the way people work. It has been my experience that people do not create different branches or smaller pull requests because the build would start from scratch!

This should be fixed. It is not just a miss-documentation.

Originally posted by @aminya in #79

The security concerns can be addressed by making this opt-in and having a flag to limit it to the previous contributors of the repo.

[mrousavy]

Love this! This makes cache usable for GitHub releases.

[jshier]

As you can tell from previous feedback, cross-branch caching is the obvious expected behavior, and is the default in every other CI service I've used (GitLab, CircleCI, the old TravisCI, Jenkins with particular plugins). Right now you have thousands and thousands of jobs running with users thinking they are cached when they are not, wasting time and money.

While GitHub considers whether or not to match every other service, all documentation around caching, both within this repo and across GitHub, should be updated to call this out. Every page mentioning caching should have a big bold header:

Caches Only Apply Within A Single Branch

[tony-pizza]

@joshmgross As a disgruntled dev migrating to GH Actions from another CI provider for a private repo your summary did help me better understand the security concerns regarding public repos. Thank you. My takeaway is that GitHub approaches things security-first and open-source-community-first (aka public-repo-first), and hey, that's great. But to me it feels like GitHub's not really considering their customer base who work on private repos (where branch-level isolation is usually not a default security concern). For instance, you say:

This level of isolation is critical to the security model for caching - without it caches would be a shared resource across all Actions workflow runs in a repository.

And to that I say: Branch-level isolation is not a security model that makes sense for my repo. Having caches shared across all workflow runs in a repo is exactly what I want. Working in a private repo where all contributors are trusted developers, cache poisoning attacks are not even on my radar. I can appreciate that public repos have unique security concerns, but the lack of flexibility here is clearly impacting many users who work in contexts where this security model is not a good fit. And it confuses people coming from other CI platforms where this is generally not the default.

It's pretty basic, but since you're looking to gather use cases I'll share mine: I develop on an org's private repo with over 50 contributors who are all trusted. We have actions that run tests on PRs and merge groups. We want to cache stuff like test database setup, node modules, ruby gems, etc to help speed up our jobs by not running from scratch each time. The cache keys for these can be easily computed by hashing files in our repo and I want them to be shared across branches and merge groups so that the cache isn't empty on every first run for a branch or merge group. Because we run tests on merge groups we don't run tests on main and thus cannot use the cache from our default branch in feature branches.

Examples of how other services treat open-source repos:

• CircleCI enforces cache isolation per repo/fork rather than per branch
• GitLab allows you to opt-out of branch-level isolation via a setting

[garysassano]

I'd like to better understand the security concerns, particularly for the use case described in my issue (#1496).

Consider this common workflow:

1. A feature branch is developed.
2. A pull request is opened to merge this feature branch into main (default branch).
3. The workflow triggered by the pull request builds a Docker image and caches it.
4. This pull request is then reviewed, approved, and merged into main.

In this scenario, why is the subsequent workflow run on the main branch unable to reuse the Docker image that was cached during the pull request workflow from the (now merged) feature branch? Given that the changes were vetted and approved through the PR process before merging, forcing a rebuild of the same image on main seems counterintuitive and inefficient.

[kamzil]

Why did you close the issue with lots of upvotes and open a new discussion for this topic, when just a simple look at https://github.com/orgs/community/discussions/27059 could give you enough info that lots of users want more control around this restriction and to be able to have repository-wide scope for cache?