On Wed, Apr 3, 2024 at 3:42 PM Daniel Gustafsson <daniel@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
