While #xz has people talking about issues with binary test files etc in source repos, and issues with using tarballs that can vary from git, doing a `git clone`
and building in there is *also* exposed to a huge amount of binary data.
Including binary data hidden inside #git commit objects, for example. Also git blobs are zlib compressed so might be possible to smuggle in extra binary data at the end. Possibly also at the end of tree objects, I don't remember if git checks for that.
@joeyh I think this is going to push me even further into the "no generated content in #git" camp. Got a weird binary bit of test data? Write down the steps you use to make it, write down the code that automates those steps, and include that instead, so you can generate the binaries on the fly as a part of the build/test cycle.
@eighthave @joeyh My usual (slightly glib) response is that is to remind people how time-consuming dealing with the consequences of that generated content in the long term could be. 😛
@atrus @joeyh I think a more useful and realistic takeaway from the #xz #backdoor is that build systems should be clean, direct, simple, and easily readable. A key part was the m4 code in the build system that read the payload from the obfuscated test file. If the build system was easy to read, then it would have been a lot harder to do that.
