Re: Security lessons from liblzma

On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson <daniel(at)yesql(dot)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?

> 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.

--
Robert Haas
EDB: http://www.enterprisedb.com