On 30.03.24 00:14, Daniel Gustafsson wrote:
> One take-away for me is how important it is to ship recipes for regenerating
> any testdata which is included in generated/compiled/binary format. Kind of
> how we in our tree ship the config for test TLS certificates and keys which can
> be manually inspected, and used to rebuild the testdata (although the risk for
> injections in this particular case seems low). Bad things can still be
> injected, but formats which allow manual review at least goes some way towards
> lowering risk.
I actually find the situation with the test TLS files quite
unsatisfactory. While we have build rules, the output files are not
reproducible, both because of some inherent randomness in the
generation, and because different OpenSSL versions produce different
details. So you just have to "trust" that what's there now makes sense.
Of course, you can use openssl tools to unpack these files, but that
is difficult and unreliable unless you know exactly what you are looking
for. Also, for example, do we even know whether all the files that are
there now are even used by any tests?
A few years ago, some guy on the internet sent in a purported update to
one of the files [0], which I ended up committing, but I remember that
that situation gave me quite some pause at the time.
It would be better if we created the required test files as part of the
test run. (Why not? Too slow?) Alternatively, I have been thinking
that maybe we could make the output more reproducible by messing with
whatever random seed OpenSSL uses. Or maybe use a Python library to
create the files. Some things to think about.
[0]:
https://www.postgresql.org/message-id/FEF81714-D479-4512-839B-C769D2605F8A%40yesql.se