public inbox for [email protected]  
help / color / mirror / Atom feed
From: Jacob Champion <[email protected]>
To: Jonathan Gonzalez V. <[email protected]>
Cc: Zsolt Parragi <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode
Date: Tue, 16 Dec 2025 11:16:41 -0800
Message-ID: <CAOYmi+mMx1DnNpKG8RdknH0-GuPR9jv+G9r2iFND=Yve7DOF6g@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
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>
	<[email protected]>

On Sun, Dec 14, 2025 at 3:13 AM Jonathan Gonzalez V.
<[email protected]> 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_feature
>
> 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 AM Jonathan Gonzalez V.
<[email protected]> 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





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: <CAOYmi+mMx1DnNpKG8RdknH0-GuPR9jv+G9r2iFND=Yve7DOF6g@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