I assume they're referring to Steve Jobs' comments in this (Robert Cringely IIRC) interview: https://www.youtube.com/watch?v=l4dCJJFuMsE (not a great copy, but should be good enough)
First they need to gain some credibility. And they also need to obfuscate what they were trying to do. The payoff if they were to succeed is potentially enormous, so it makes sense to do things slowly.
> and why do it in xz?
xz is almost a perfect target- undermaintained, complicated code that isn't well understood by many people, deployed and used widely.
> Or are they also attacking lots of other systems, perhaps under other names?
The answer probably depends who the attacker(s) are, and what sort of funding or other motifivations they have. We can only guess.
> 4. And what can we do about these attacks?
This is a big unanswered question. I haven't seen any great suggestions yet. We were very lucky with this particular attack.
> How can we build a system that isn’t ultimately brought crashing down by one or two bad actors?
The complexity involved in this attack suggests that it was probably a group, IMO.
> 5. Small technical detail I haven’t spotted in writeups: was the attack commands signed in some way so only the attacker can use it and the world can go hunting for a smoking gun cert that matches the attacker?
Fun fact for the non-Australians, the actor who plays Bandit is part of an awesome indie-rock band named Custard formed in the late 80s. Worth checking out if you're into that sort of thing.
If you're only using remote caching (ie no remote execution) then all cache clients need to trust each other, because a malicious client can upload any result it wants to a given ActionCache key, and there's no way to verify the ActionCache entries are correct unless the actions are reproducible. (And verifying ActionCache entries by rerunning the actions kind of defeats the purpose of using a build cache.)
If you don't want clients to have to trust each other, then you can block ActionCache write access to the clients and add remote execution. In this setup clients upload an action to the CAS, remote executors run the action and then upload the result to the ActionCache, using the hash of the action as the key. This way malicious clients can't spoof cache results for other clients, because other clients won't ever look for the malicious action's key in the ActionCache.
They are still used in some places. But they have some downsides:
Precompiled headers don't play nicely with distributed compilation or shared build caches (which are perhaps the fastest way to build large C++ codebases). So while they can work well for local builds, they exclude the use of (IMO) better build-time optimisations.
They also require maintenance over time- if you precompile a bad set of headers it can make your compile times worse.
There's also an opensource goma client + server which proxies to RBE (or potentially other bazel remote execution API implementations). Which is great if you can't or don't want to use the bazel client, but can use a compiler wrapper.
https://www.smh.com.au/technology/adobe-chief-dodges-questio...