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

• Same cache key not shared between different pull requests #79
• Allow caching for deployment events or other events without GITHUB_REF #319
• Using cache with git tags #1371
• Cache created in feature branch not usable in the default branch (main) #1496
• Support cache for merge queues #1537
• Support crossTag and crossBranch #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.