Is a remote build cache safe? Who can write to it
+A build cache speeds up builds, and if it is down or empty, builds are only slower. The risk is different: a cache that serves the wrong files. That depends on who can write to it.
+ +Two kinds of failure
+-
+
- Down, empty or unreachable. Builds run slower. Nothing is lost and nothing is wrong. A build cache is only slower in this case. +
- Serving wrong files. If something untrusted can write to the cache, it can change what later builds use as task outputs. This is a different class of problem, and it is the one to plan for. +
Treat it as part of your supply chain
+Anyone who can write to the cache can influence your builds. So:
+-
+
- Turn on Basic Auth anywhere untrusted parties could reach the port. +
- Share the read-write password only with CI and the developers you already trust to change your code. +
- Give everyone else the optional read-only login. A client using it can read cache entries, and any write gets a 403. +
- Use HTTPS in real deployments. Gradle sends the password with every request. +
"Push disabled" is not a permission
+Setting isPush = false in a Gradle config is the client choosing not to upload. It is not a rule on the server. A client that holds the read-write password can still write. The server-side rule is the read-only login.
What is not built yet
+There is no per-person identity. A read-write login is shared by whoever holds it, so you cannot tell which writer did what.
+ +A simple setup
+-
+
- CI holds the read-write login and uploads. +
- Developer laptops hold the read-only login and download. +
- The server sits behind HTTPS, on a network you control. +
The Jenkins and CI page shows how to wire it: Jenkins and CI build cache.
+ +Related: what to check in a replacement build cache and security policy.
+ +