Hacker News Reader

Comment by __float | Hacker News Reader

Is this only a remote cache for Bazel, but it does not support the remote execution API at all? It's a little worrisome to trust all user outputs when you do not also control the execution of them. (In the "best" case this could mean caching non-reproducible ("works on my machine") build results, in the worst case this could be actively dangerous if a malicious user poisons the build cache.)

View on HN

It’s only a remote cache and that’s deliberate. We see it as much safer to only offer a cache that the user can control and use however they want

We would see taking over execution of your build as much more dangerous.

No question though that build caching in shared form, in SaaS form, needs extra special attention paid to security. Our product doesn’t introspect cache blobs and in fact doesn’t really want to. Once we figure out how to make the crypto work, we shouldn’t be able to see any of that data at all.

Access can be made public for reads (OSS) but is always identified for writes.

(Also, speaking as a Bazel user now, the Remote Execution APIs have always been a bit brittle and hard to setup, use, and maintain; certainly harder than just setting a cache endpoint.

I’ve found that remote execution ends up returning much less benefit than remote caching, but that’s just me and it’s entirely possible I Did It Wrong the whole time)

Reply on news.ycombinator.com