Feedback-ID: id4a34324:Fastmail
Date: Fri, 12 Apr 2024 09:00:11 -0700
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Magnus Hagander <magnus@hagander.net>, Bruce Momjian <bruce@momjian.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Security lessons from liblzma - libsystemd
Message-ID: <20240412160011.stodfnsae6o7oszn@awork3.anarazel.de>
References: <ZgdCpFThi9ODcCsJ@momjian.us>
 <20240403175721.l4r55sw4vcsrgpww@awork3.anarazel.de>
 <CABUevExoimjHPMMpAegci5mX13uOSPbZcWvycbwZwgey3c6P_w@mail.gmail.com>
 <7af9c295-1ea8-45ba-ad71-93ac2fae2e89@eisentraut.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7af9c295-1ea8-45ba-ad71-93ac2fae2e89@eisentraut.org>
Archived-At: <https://www.postgresql.org/message-id/20240412160011.stodfnsae6o7oszn%40awork3.anarazel.de>
Precedence: bulk

Hi,

On 2024-04-04 01:10:20 +0200, Peter Eisentraut wrote:
> On 03.04.24 23:19, Magnus Hagander wrote:
> > When the code is this simple, we should definitely consider carrying it
> > ourselves. At least if we don't expect to need *other* functionality
> > from the same library in the future, which I doubt we will from
> > libsystemd.
> 
> Well, I've long had it on my list to do some integration to log directly to
> the journal, so you can preserve metadata better.  I'm not sure right now
> whether this would use libsystemd, but it's not like there is absolutely no
> other systemd-related functionality that could be added.

Interesting. I think that'd in all likelihood end up using libsystemd.


> Personally, I think this proposed change is trying to close a barndoor after
> a horse has bolted.  There are many more interesting and scary libraries in
> the dependency tree of "postgres", so just picking off one right now doesn't
> really accomplish anything.  The next release of libsystemd will drop all
> the compression libraries as hard dependencies, so the issue in that sense
> is gone anyway.  Also, fun fact: liblzma is also a dependency via libxml2.

I agree that doing this just because of future risk in liblzma is probably not
worth it. Despite soon not being an unconditional dependency of libsystemd
anymore, I'd guess that in a few months it's going to be one of the better
vetted libraries out there.  But I don't think that means it's not worth
reducing the dependencies that we have unconditionally loaded.

Having a dependency to a fairly large library (~900k), which could be avoided
with ~30 LOC, is just not worth it. Independent of liblzma. Not from a
performance POV, nor from a risk POV.

I'm actually fairly bothered by us linking to libxml2. It was effectively
unmaintained for most of the last decade, with just very occasional drive-by
commits. And it's not that there weren't significant bugs or such. Maintenance
has picked up some, but it's still not well maintained, I'd say.  If I wanted
to attack postgres, it's where I'd start.

My worry level, in decreasing order, about postmaster-level dependencies:
- libxml2 - effectively unmaintained, just about maintained today
- gssapi - heavily undermaintained from what I can see, lots of complicated code
- libldap - undermaintained, lots of creaky old code
- libpam - undermaintained, lots of creaky old code
- the rest

Greetings,

Andres Freund