cache

This is GitHub FU. Key issue here is cache poisoning, that is feature/bug that exist in utility functions/actions provided by Github. Even if there was misconfiguration on tanstack side, then root cause is on. GH for even allowing insecure workflows to interfere with secure ones. Here people are trying to fix defaults - not to write cache in insecure context -> https://github.com/actions/cache/issues/1756 (even if sufficiely smart attacker would find the key somewhere and skip this kind of prodection, not sure where but write-allowing-key it must exist somewhere in runtime if actions/cache can us it) Someone else on this thread: > On GitLab even if you set the same cache key it will not cross between unprotected and protected runs.

> Do you use the proprietary github actions stuff? If I can avoid it, no. Almost everything I can control is outside of the Microsoft ecosystem. But as a freelancer, I have to deal a bunch with GitHub and Microsoft anyways, so in many of those cases, yes. Many times, I end up using https://github.com/actions/cache for the clients who already use Actions, and none of that runs in the local machines at all. Typically I use a single Makefile/Justfile, that sometimes have most of the logic inside of it for running tests and what not, sometimes shell out to "proper" scripts. But that's disconnected from the required "setup", so Make/Just doesn't actually download dependencies, that's outside of the responsibilities of whatever runs the test. And also, with a lot of languages, it doesn't matter if you run an extra "npm install" over already exi