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
