Re: Security lessons from liblzma

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Andres Freund <andres@anarazel.de>, Bruce Momjian <bruce@momjian.us>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-04-04T20:25:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Introduce a non-recursive JSON parser

> On 4 Apr 2024, at 21:38, Robert Haas <robertmhaas@gmail.com> wrote:

> Essentially, your argument is the same as his, namely: hey, don't
> worry, you could totally verify these test files if you wanted to! But
> of course, nobody did, because it was hard, and everybody had better
> things to do with their time. And I think the same thing is probably
> true here: nobody really is going to verify much about these files.

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.

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?

--
Daniel Gustafsson