MIME-Version: 1.0
References: <16a91d02795cb991963326a902afa764e4d721db.camel@gmail.com>
 <3D82D240-1CC5-4CE6-BE30-6065B693D40C@yesql.se>
 <CAOYmi+=fbZNJSkHVci=GpR8XPYObK=H+2ERRha0LDTS+ifsWnw@mail.gmail.com>
 <CAN4CZFPhm2NCRWzZpX=kRLqyxu4Ps-d0xE5W75a-iDoKrLbXBw@mail.gmail.com>
 <CAOYmi+=HcXJub1rDsQ7vpKMHuBB6NTA2Z5T=zAkaFdRThf+9zg@mail.gmail.com>
 <CAN4CZFNvZ9+pQ=OA4m=HcDgip84GHnekh4gUhYWfK3Q4+rBMxA@mail.gmail.com>
 <CAOYmi+niKkCj-wNnsqXf9KVB_U+tdpuqRQjT_ZYpJ9hC__RBHg@mail.gmail.com>
 <CAN4CZFPF9MxNj6UvJOqOR-DJi8+AVJusBW2LSQrn2hgXn818WQ@mail.gmail.com>
In-Reply-To: 
 <CAN4CZFPF9MxNj6UvJOqOR-DJi8+AVJusBW2LSQrn2hgXn818WQ@mail.gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Thu, 18 Dec 2025 09:51:20 -0800
Message-ID: 
 <CAOYmi+mVX5rKfvsCVVYM8ZDEBaNDO83TBLPURFuEgA8gbsU8Zw@mail.gmail.com>
Subject: Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Daniel Gustafsson <daniel@yesql.se>,
 "Jonathan Gonzalez V." <jonathan.abdiel@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2BmVX5rKfvsCVVYM8ZDEBaNDO83TBLPURFuEgA8gbsU8Zw%40mail.gmail.com>
Precedence: bulk

On Wed, Dec 17, 2025 at 5:15=E2=80=AFAM Zsolt Parragi <zsolt.parragi@percon=
a.com> wrote:
> > I don't disagree. But at this point in these conversations, the
> > question posed is typically "is the new risk/reward tradeoff any worse
> > than PGSSLROOTCERT or PGSSLMODE or PGSERVICEFILE (or LD_LIBRARY_PATH
> > or PATH)?" I'd say no, not enough to introduce a new way of
> > configuring things for this particular setting.
>
> Those are also bad, but there are also parameter alternatives for all of =
them.

But if the concern is security, the existence of the parameter
alternatives doesn't really seem to help you.

> > 2) Do you want these settings to be part of a postgres:// URI?
>
> Not for debug settings, but if everyone agrees on splitting the CA
> into its own setting, it could behave the same way as
> sslrootcert/PGSSLROOTCERT.

I don't know if everyone does, but I've seen no pushback yet, so I
plan to do so (parameter + envvar).

I only nested it under debug settings because I thought there was no
production use case, and now that Jonathan is saying "yes, I have a
production case", that seems good enough. I don't think I need to
raise the bar any more than that.

> > Mmm... I'd say that application developers always have to be aware of
> > user environment changes in the context of any Linux programming, let
> > alone libpq client development. The user is generally in partial
> > control of the linker. Nearly every libpq setting is accessible via
> > the environment. (setuid programming is its own specialized skillset
> > for a reason.)
>
> My concern is not somebody developing libpq directly on Linux, but
> more complex situations.

Understood (and I'd like to make this better too). But see below.

> This is also probably a separate discussion, but what do you think
> about introducing a parameter that disables environment variable
> fallbacks? Both for existing variables like PGSSLROOTCERT and
> new/debug variables like PGOAUTHCAFILE. (by default everything works
> as currently; when specified environment variables are ignored)

I like the idea of more application control over this, generally. I
think the concern that's been raised before, for example with the
superuser-can-do-too-much conversations, is: Piecemeal improvements,
without a consensus on the end goal, can paradoxically make things
less secure. Because now users have a harder time reasoning about the
system's behavior and designing for it. It's even worse if committers
can't reason about it and start working at cross purposes.

For example, if we lock down our envvars and then immediately farm
security-critical decisions out to Kerberos or Curl or PAM or etc.
which use their own envvars, in what cases is that better than telling
application developers that hey, you always need to be careful about
sanitizing your environment if you somehow don't trust it? I don't
really know (hand-wavy), and I think proposals would need to provide
good arguments in favor. Definitely a separate discussion.

Thanks,
--Jacob