Thread

Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode

Jacob Champion <jacob.champion@enterprisedb.com> — 2025-12-16T19:16:41Z

On Sun, Dec 14, 2025 at 3:13 AM 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_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.
<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