On Wed, Apr 3, 2024 at 3:42 PM Daniel Gustafsson <dan...@yesql.se> wrote: > > So you just have to "trust" that what's there now makes sense. > > Not entirely, you can review the input files which are used to generate the > test data and verify that those make sense..
Yeah, I mean, in theory I suppose that's true, but look at this commit: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=6e636819e8f070330d835fce46289a3ff72a7b89 In case the link stops working for some reason, the commit message is as follows: JT> Tests: Update two test files. JT> JT> The original files were generated with random local to my machine. JT> To better reproduce these files in the future, a constant seed was used JT> to recreate these files. Essentially, your argument is the same as his, namely: hey, don't worry, you could totally verify these test files if you wanted to! But of course, nobody did, because it was hard, and everybody had better things to do with their time. And I think the same thing is probably true here: nobody really is going to verify much about these files. I just went and ran openssl x509 -in $f -text on each .crt file and it worked, so all of those files look basically like certificates. But like, hypothetically, how do I know that the modulus chosen for a particular certificate was chosen at random, rather than maliciously? Similarly for the key files. Are there padding bytes in any of these files that could be used to store evil information? I don't know that, either. I'm not sure how far it's worth continuing down this path of paranoia; I doubt that Daniel Gustafsson is a clever alias for a nefarious cabal of state-sponsored hackers, and the hypotheses that supposedly-random values were chosen non-randomly borders on unfalsifiable. Nonetheless, I think Peter is correct to point out that these are the kinds of files about which it is reasonable to be concerned, because they seem to have properties quite similar to those of the files used in an actual attack. -- Robert Haas EDB: http://www.enterprisedb.com
