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>
In-Reply-To: 
 <CAOYmi+niKkCj-wNnsqXf9KVB_U+tdpuqRQjT_ZYpJ9hC__RBHg@mail.gmail.com>
From: Zsolt Parragi <zsolt.parragi@percona.com>
Date: Wed, 17 Dec 2025 13:15:30 +0000
Message-ID: 
 <CAN4CZFPF9MxNj6UvJOqOR-DJi8+AVJusBW2LSQrn2hgXn818WQ@mail.gmail.com>
Subject: Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode
To: Jacob Champion <jacob.champion@enterprisedb.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"
Archived-At: 
 <https://www.postgresql.org/message-id/CAN4CZFPF9MxNj6UvJOqOR-DJi8%2BAVJusBW2LSQrn2hgXn818WQ%40mail.gmail.com>
Precedence: bulk

> 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.

> 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.

> Because it's not obviously spraying output all the time, you mean? We
> could perhaps be noisier when any UNSAFE setting is in use.

Yes, mainly that. And as you mentioned there's already existing
behavior like that in the code, so it's nothing new.

> Yeah, I'm not entirely happy about it either. Let me think about some
> alternatives...

I'll try these suggestions and see what they look like - and I'll
start a separate thread with it so that this thread can focus on the
CA variable.

> 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.

For example:

1. there is libpq
2. libpq is used by scripting language bindings for python/ruby/etc
3. language libraries are used in ORM frameworks, which have their own
configuration interface
4. ORM frameworks are used in web frameworks / other libraries
5. those frameworks/libraries get used by somebody writing an actual
webpage/application
6. And that webpage/application gets installed/maintained by an
administrator/user, who might or might not be aware of this

And we also have Windows/other platforms, where environment variables
are less visible.

> Now, if there's any appetite to make the situation better, continuing
> to add security-critical settings into the environment makes things
> worse for anyone who wants to propose an alternative

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)