> merges hidden backdoor binary code well hidden inside some binary test input files. [...] Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves.
So much for the folks advocating for binary (driver) blobs in OSS t support otherwise unsupported hardware.
It's either in source form and reproducable or it's not there.
>It's either in source form and reproducable or it's not there.
Wanna know how I know you haven't read into the discussion much?
There are a whole lot of binary test cases in software. Especially when you're dealing with things like file formats and test cases that should specifically fail on bad data of particular types.
> There are a whole lot of binary test cases in software.
That's not how I read GP's point. If even binary blobs in test cases are a place where backdoors are, now as a matter of fact, hidden then, certainly, among the folks advocating for binary drivers in FOSS, there are some who are already --or planning to-- add backdoors there.
Binary blobs are all terrible, terrible, terrible ideas.
Builds should be 100% reproducible from source, bit for bit. At this point it's not open up for discussion anymore.
Then you figure out how to build a 'source' test case of a bad zip, or bad jpg, or word document or whatever else exists out there. Also figure out how to test that your bit4bit perfect binary isn't doing the wrong damned thing in your environment with actual real data.
In cryptography, there's the concept of a nothing-up-my-sleeve number. [1]
Instead of obscure constants, you use known constants, or at least simple methods to derive your constants.
You can do the same thing to come up with your test cases.
Bad zip? Construct a good zip of 10 files, each containing the first 10,000 prime numbers.
Then corrupt the zip by seeking to position (100/pi) and write a thousand zeroes there.
Bad JPEG? Use Imagemagick to render the first 1000 prime numbers as text into a JPEG file, then apply a simple nothing-up-my-sleeve corruption operation.
There are still cases where this approach isn't going to work: that new icon, helpfully proposed by a contributor, meant to be used in production, might contain malicious code, steganographically embedded. I think there's little you can do to prevent that.
So much for the folks advocating for binary (driver) blobs in OSS t support otherwise unsupported hardware.
It's either in source form and reproducable or it's not there.