[bastih]

To combat this scenario, we only had build servers populate the cache. Clients were readonly to the cache, so they would benefit from anything that build servers had already built, which covered 95%+ of what clients usually had to rebuild.

Also release builds were excluded from caching, to prevent any form of poisoning there.

[iveqy]

How did you know that the build servers only built trusted code?

[account42]

The threat is not that the cache contains builds of untrusted code but that it contains builds that do not match the code that they are associated with.

[Tobu]

As far as I'm aware (ICEs…) compilers aren't hardened against untrusted code, and a sufficiently capable exploit could be used to poison the cache.

[jonstewart]

ccache uses cryptographic hashing of file contents, in addition to matching compiler arguments, so you can be sure that the code matches.

[slavik81]

It uses a cryptographic hash of the _inputs_ to the compiler, but there is no way to verify that the cached artifact matches the _output_ of the compiler without actually compiling it yourself.

[williamcotton]

Public-key cryptography?

[williamcotton]

Here, let me explain how it works!

Let’s say you have 15 engineers and they each have their own laptop computer. Each of these engineers generates a pair of cryptographic keys, one public and one private.

Each engineer then gives their public key to the trusted authority that operates the ccache server. Only code that is submitted and signed by a respective private key is built and then distributed to the rest of the engineers.

[gdhdjdvr]

So what you are talking about is gpg signed git commits and a private ci doing the building...?

[williamcotton]

That’s one way to do it!

For a public project you would only want the builds to be propagated out to other developers once the changes had been approved and then merged into a branch that triggers the CI.