Re: Security lessons from liblzma

I looked through the repositories of 19 linux distros [1] to see what 
kind of patches are applied often. Many of them share the same package 
managers / repositories and thus the same patches. I made sure to look 
at some smaller, "other" distros as well, to see what kind of problems 
appear outside the mainstream distros.

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

+1. Other paths, which some distros need to configure are pkgincludedir 
and pgxs (independently of pkglibdir).

Also a configurable directoy to look up extensions, possibly even to be 
changed at run-time like [2]. The patch says this:

> This directory is prepended to paths when loading extensions (control and SQL files), and to the '$libdir' directive
whenloading modules that back functions. The location is made configurable to allow build-time testing of extensions
thatdo not have been installed to their proper location yet.
 

This seems like a great thing to have. This might also be relevant in 
light of recent discussions in the ecosystem around extension management.

All the path-related issues have in common, that while it's easy to move 
files around to their proper locations later, they all need to adjust 
pg_config's output.


Andres Freund:
> 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.

DEFAULT_PAGER is also overriden by a few distros. DEFAULT_EDITOR by one 
as well. As you said DEFAULT_PGSOCKET_DIR in **a lot** of them.


Andres Freund:
> 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?

+1 for that option to force the suffix, no matter whether postgres/pgsql 
are in the path already.


Some other commonly patched issues are:
- Building only libpq, only libecpg - or disabling both and building 
only the server code. This comes up often, it's not supported nicely in 
our build system, yet. I think meson already has some build targets for 
parts of that, but it's very hard / impossible to then install only this 
subset of the build. It would be great to be able to build and install 
only the frontend code (including only the frontend headers) or only the 
backend code (including headers) etc.
- Related to the above is pg_config and how to deal with it when 
installing separate client and server packages, in different locations, 
too. Some distros provide a second version of pg_config as pg_server_config.

Those two issues and the path-related issues above make it harder than 
it should be to provide separate packages for each major version, which 
can be installed at the same time (versioned prefixes, multiple server 
packages, but maybe only a single libpq package etc.).


Some small patches that might not be widespread, but could possibly 
still be upstreamed:
- jit-s390x [3] (Alpine, Debian, Fedora, openSUSE)
- pg_config --major-version option for extension builds [4] (Alpine)
- Some fixes for man pages [5] (AlmaLinux, CentOS, Fedora)


TLDR: I think it should be possible to make the build system more 
flexible in some areas without introducing distro specific things in 
core. This should eliminate the need for many of the same patches across 
the board for a lot of distros.

Best,

Wolfgang

[1]: ALT Linux, Adélie Linux, AlmaLinux, Alpine Linux, Arch Linux, 
CentOS, Crux, Debian, Fedora, Gentoo, GoboLinux, Guix, Mandriva, NixOS, 
OpenWRT, Rocky Linux, Ubuntu, Void Linux, openSUSE

[2]: 
https://salsa.debian.org/postgresql/postgresql/-/blob/17/debian/patches/extension_destdir?ref_type=heads

[3]: 
https://salsa.debian.org/postgresql/postgresql/-/blob/17/debian/patches/jit-s390x?ref_type=heads

[4]: 

https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/postgresql16/pg_config-add-major-version.patch?ref_type=heads

[5]: 
https://gitlab.com/redhat/centos-stream/rpms/postgresql/-/blob/c9s/postgresql-man.patch