Re: Security lessons from liblzma

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Security lessons from liblzma
Date: 2024-04-04 20:56:01
Message-ID: EB19ED9B-DCD8-496A-A1D3-D367A4CB0A53@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 4 Apr 2024, at 22:47, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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?
>
> IIUC, it's not really that, but that regenerating these files is
> expensive; multiple seconds even on fast machines. Putting that
> into tests that are run many times a day is unappetizing.

That's one aspect of it. We could cache the results of course to amortize the
cost over multiple test-runs but at the end of the day it will add time to
test-runs regardless of what we do.

One thing to consider would be to try and rearrange/refactor the tests to
require a smaller set of keys and certificates. I haven't looked into what
sort of savings that could yield (if any) but if we go the route of
regeneration at test-time we shouldn't leave potential savings on the table.

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-04-04 21:00:51 Re: Streaming read-ready sequential scan code
Previous Message Bruce Momjian 2024-04-04 20:51:50 Re: Reports on obsolete Postgres versions