2 ms·
If you think about it this is a data-providence problem though. The exploit was hidden in "test" code which gets included in release code by compiler flags. No
by XorNot 3y ago
If you think about it this is a data-providence problem though. The exploit was hidden in "test" code which gets included in release code by compiler flags.
Now, if there was a proper chain of accountability for data, then this wouldn't have been possible to hide the way it is - any amount of pre-processing resulting in the release tarball including derived products of "test" files would be suspicious.
The problem is we don't actually track data providence like this - no build system does. The most we do is <git hash in> -> <some deterministic bits out>. But we don't include the human readable data which explains how that transform happens at enough levels.
- paulmd 3y agoYou don’t need to go to that extent even - simply properly segregating test resources from dist resources would have prevented this, and that’s something Java has been doing for 20 years. It’s not sufficient against a determined attacker, but it does demonstrate just how unserious the C world is about their build engineering. I literally can’t think of a single time in 15 years of work that I’ve ever seen a reason for a dist build to need test resources. That’s at best a bug - if it’s a dist resource it goes in the dist resources, not test. And if the tooling doesn’t do a good job of making that mistake difficult… it’s bad tooling.