Re: Security lessons from liblzma - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Security lessons from liblzma
Date
Msg-id 20240331211257.wmrvitpxqrzdkwkn@awork3.anarazel.de
Whole thread Raw
In response to Re: Security lessons from liblzma  (Michael Banck <mbanck@gmx.net>)
Responses Re: Security lessons from liblzma
Re: Security lessons from liblzma
Re: Security lessons from liblzma
List pgsql-hackers
Hi,

On 2024-03-31 12:18:29 +0200, Michael Banck wrote:
> If you ask where they are maintained, the answer is here:
>
> https://salsa.debian.org/postgresql/postgresql/-/tree/17/debian/patches?ref_type=heads
>
> the other major versions have their own branch.

Luckily these are all quite small, leaving little space to hide stuff.  I'd
still like to get rid of at least some of them.

I've previously proposed a patch to make pkglibdir configurable, I think we
should just go for that.

For the various defines, ISTM we should just make them #ifndef guarded, then
they could be overridden by defining them at configure time. Some of them,
like DEFAULT_PGSOCKET_DIR seem to be overridden by just about every
distro. And others would be nice to easily override anyway, I e.g. dislike the
default DEFAULT_PAGER value.


On 2024-03-31 16:55:26 +0100, Devrim Gündüz wrote:
> Here are the v17 patches:
>
> https://git.postgresql.org/gitweb/?p=pgrpms.git;a=tree;f=rpm/redhat/main/non-common/postgresql-17/main

A bit bigger/more patches, but still not too bad.

postgresql-17-conf.patch

Uncomments a few values to their default, that's a bit odd.


postgresql-17-ecpg_config.h:
postgresql-17-pg_config.h:

Hm, wonder if we should make this easier somehow. Perhaps we ought to support
installing the various *config.h headers into a different directory than the
architecture independent stuff?  At least on debian based systems it seems we
ought to support installing pg_config.h etc into /usr/include/<tripplet> or
something along those lines.


postgresql-17-rpm-pgsql.patch:

We should probably make this stuff properly configurable. The current logic
with inferring whether to add /postgresql is just weird. Perhaps a configure
option that defaults to the current logic when set to an empty string but can
be overridden?


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Security lessons from liblzma
Next
From: Maiquel Grassi
Date:
Subject: RE: Psql meta-command conninfo+