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>
 <b08bf613bba131eaf15ac163d84604db452d4fde.camel@gmail.com>
In-Reply-To: <b08bf613bba131eaf15ac163d84604db452d4fde.camel@gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Tue, 16 Dec 2025 11:16:41 -0800
Message-ID: 
 <CAOYmi+mMx1DnNpKG8RdknH0-GuPR9jv+G9r2iFND=Yve7DOF6g@mail.gmail.com>
Subject: Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode
To: "Jonathan Gonzalez V." <jonathan.abdiel@gmail.com>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>,
 Daniel Gustafsson <daniel@yesql.se>,
	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%2BmMx1DnNpKG8RdknH0-GuPR9jv%2BG9r2iFND%3DYve7DOF6g%40mail.gmail.com>
Precedence: bulk

On Sun, Dec 14, 2025 at 3:13=E2=80=AFAM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> wrote:
> > Okay, that's good to know. But I'm still missing how the end user (a
> > human) trusts that magic CA within the browser or device they use to
> > finish the actual flow?
>
> More than the end user "trusting" a "magic" CA, it's about what company
> will tell you to use a CA

Sure, but my question isn't about the trust model. Just to confirm:
you're saying that it's common for enterprise provisioning apps
(CrowdStrike et al) to push CAs directly into a browser trust store,
but _not_ to the system trust paths?

> Totally agree, now I'm thinking the same, it should be a feature
> because there's more examples that I've been thinking about that may
> require this to be even a bit more flexible, for example, when working
> with edge computing, if you want (in the future because now it's not
> possible, yet) authenticate a device against PostgreSQL it may require
> to have that CA as a encoded string int he variable, not just as a
> file, wild thought I know, but it may make sense

I think we want to keep these on disk; no reason to run up against
resource limits on the environment.

> > https://wiki.postgresql.org/wiki/Proposal:_Promote_PGOAUTHCAFILE_to_fea=
ture
>
> How can we work on that? because of the above it may be required to add
> even more possibilities.

Not sure what you mean. I think we're working on it now, in this thread?

On Sun, Dec 14, 2025 at 3:17=E2=80=AFAM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> wrote:
> I will for sure try to avoid this kind of format with comma separated
> options, this mainly because are really hard to parse and manage in an
> automated way

I feel _very_ strongly that the "debug" options are for people.
Specifically developers who are debugging. What use case do you have
for automation and parsing outside of libpq?

> and sometimes, are hard to read when there's too many
> options, and at some point, there could be many options since the flows
> can start getting really complicated.

Can you explain more about what kinds of use cases would lead to
option explosion? When I'm developing I typically want to export an
interesting group of options once, and then not think about it for a
while. When debugging in production I typically want one particular
thing at a time.

> Why not keep something with debug levels? Even if it sounds really
> classic, for parsing reasons are really good.

I would say: because there's no natural order to the settings. It's a
bunch of on/off behaviors, some of which are safety-critical. What is
the "debug level" of disabling encryption compared to the debug level
of printing secrets or turning off parameter validation?

--Jacob