On Fri, Apr 05, 2024 at 11:40:46AM -0700, Jacob Champion wrote: > On Fri, Apr 5, 2024 at 6:24 AM Robert Haas <robertmh...@gmail.com> wrote: >> I'm also sort of afraid that we're getting sucked into thinking real >> hard about this SSL certificate issue rather than trying to brainstorm >> all the other places that might be problematic. The latter might be a >> more fruitful exercise (or maybe not, what do I know?). > > +1. Don't get me wrong: I spent a lot of time refactoring the sslfiles > machinery a while back, and I would love for it to all go away. I > don't really want to interrupt any lines of thought that are moving in > that direction. Please continue.
There are a few things that I've not seen mentioned on this thread. Any random byte sequences included in the tree should have ways to be regenerated. One problem with xz was that the binary blobs were directly part of the tree, with the input file and the test crafted so as the test would skip portions of the input, one line in ./configure being enough to switch the backdoor to evil mode (correct me if I read that wrong). There could be other things that one would be tempted to introduce for Postgres as test data to introduce a backdoor with a slight tweak of the source tarball. To name a few: - Binary WAL sequences, arguing that this WAL data is useful even with alignment restrictions. - Data for COPY. - Physical dumps, in raw or just SQL data. Anything like that can also be used in some test data provided by somebody in a proposed patch or a bug report, for the sake of reproducing an issue. If there is an attack on this data, another contributor could run it and get his/her own host powned. One thing that would be easy to hide is something that reads on-disk file in a large dump file, with something edited in its inner parts. An extra thing is if we should expand the use of signed commits and potentially physical keys for committers, provided by pg-infra which would be the source of trust? Some have mentioned that in the past, and this could reduce the risk of committing problematic code if a committer's host is powned because the physical key would be required. Saying that, my spidey sense tingles at the recent commit 3311ea86edc7, that had the idea to introduce a 20k line output file based on a 378 line input file full of random URLs. In my experience, tests don't require to be that large to be useful, and the input data is very hard to parse. -- Michael
signature.asc
Description: PGP signature
