[duped]

> What if your CI pipeline was old-school bash script instead?

It doesn't matter if the cache is accessed through `actions/cache` in YAML or `curl -X POST $GITHUB_CACHE_URL < wololo.exe` or whatever. The fundamental problem is that "cache scope is per-repo."

I cannot fathom why they chose to support this at all, let alone make it the default for any action trigger. Any writeable data should be scoped to users/groups and require credentials. It should be impossible to write to a shared cache without explicitly granting permissions to the user triggering the action.

And sure a PAT might leak through an env var not configured through secrets, but that's an understandable issue created by the user. I think most people are surprised their caches are world writeable with an innocuous actions trigger.

[Ciantic]

If I saw this in my CI script:

    curl -X POST $GITHUB_CACHE_URL < wololo.exe

It would make me pause, but now that it is a misfeature in YAML configuration it is more widely used. Point of bash scripts they are auditable, and understandable.

I didn't prescribe what the bash script would be, because it would differ on use case. If I wanted to share artifacts from other runs I would probably use podman and make sure I start new runs from known good condition, but because I understand that. Some other would use nix or whatever else.

[duped]

The fundamental problem is that on Github Actions it's possible to give read-only permissions to pipelines that are then violated because runners can be granted read+write permissions to the cache. And they don't consider this a P0 bug.

So you don't even need to see questionable bash scripts to know there's a problem. The script would have already completed and pwned you by the time you see it.

With podman or nix you would have to poison the container registry/nix store which is more difficult, but you're also probably using your own runners.

My point though is that it's not bash or yaml here, but Github's default access controls. If you own your own runners and your own caching layer then you're not going to be nearly as boneheaded as Github here. But Github pushes people towards their integrated solutions, which have horrible defaults.