> On 4 Apr 2024, at 22:40, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>> I don't disagree, like I said that very email: it's non-trivial and I wish we
>> could make it better somehow, but I don't hav an abundance of good ideas.
>
> Is the basic issue that we can't rely on the necessary toolchain to be
> present on every machine where someone might try to build PostgreSQL?
AFAIK we haven't historically enforced that installations have the openssl
binary in PATH, but it would be a pretty low bar to add. The bigger issue is
likely to find someone to port this to Windows, it probably won't be too hard
but as with all things building on Windows, we need someone skilled in that
area to do it.
>> Removing the generated versions and creating them when running tests makes
>> sneaking in malicious content harder since it then has to be submitted in
>> clear-text *only*. The emphasis added since it's like that today as well: *I*
>> fully trust our team of committers to not accept a binary file in a patch
>> without replacing with a regenerated version, but enforcing it might make it
>> easier for a wider community to share that level of trust?
>
> To be honest, I'm not at all sure that I would have considered
> regenerating a binary file to be a must-do kind of a thing, so I guess
> that's a lesson learned for me. Trust is a really tricky thing in
> cases like this. It's not just about whether some committer is
> secretly a malicious actor; it's also about whether everyone
> understands the best practices and follows them consistently. In that
> regard, I don't even trust myself. I hope that it's unlikely that I
> would mistakenly commit something malicious, but I think it could
> happen, and I think it could happen to anyone else, too.
It absolutelty could. Re-reading Ken Thompsons Turing Lecture "Reflections on
Trusting Trust" at periodic intervals is a good reminder to self just how
complicated this is.
--
Daniel Gustafsson