public inbox for [email protected]
help / color / mirror / Atom feedFrom: Zsolt Parragi <[email protected]>
To: Jacob Champion <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Cc: Jonathan Gonzalez V. <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode
Date: Wed, 17 Dec 2025 13:15:30 +0000
Message-ID: <CAN4CZFPF9MxNj6UvJOqOR-DJi8+AVJusBW2LSQrn2hgXn818WQ@mail.gmail.com> (raw)
In-Reply-To: <CAOYmi+niKkCj-wNnsqXf9KVB_U+tdpuqRQjT_ZYpJ9hC__RBHg@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<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>
> 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)
view thread (24+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode
In-Reply-To: <CAN4CZFPF9MxNj6UvJOqOR-DJi8+AVJusBW2LSQrn2hgXn818WQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox