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

Hi!

On Tue, 2025-12-16 at 11:16 -0800, Jacob Champion wrote:
>
> 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?

Yes! that use case it's more usual than one will expect, for example,
if you're routing different traffic for different apps into different
VPNs or routes, even between different browsers, this is also really
common now days because of the jailed-apps, something that in Linux
systems is pretty common, like snap, that create these "jailed"
environment so they can be supported across systems.

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

No questions about it! was just an option that someone may come up
with! I've seen so many weird things that people does, specially on
shell scripts.

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

Yes, but having a list of ideas listed, that we all can read may make
sense, that's because following the threads with all the ideas at once
it's a big difficult some times!

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

Well, I have something to say about.
In my opinion, "debug" it's not just developers, helps a lot when
running and managing system, specially when using new technologies
(like this one specifically), helps to understand the flow and also to
realize what's going on and tune the configurations, this it's always
very useful when managing small or large systems.
On the other hand, since all the systems now days can run on hundreds
of servers or containers, no one looks into the logs manually, you have
automated system for it, that will read, parse, collect and distribute
your logs into different storage, databases(even PostgreSQL database
can be used for it) or display system. It is for theses cases that
having something that can be parsed is always useful.

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

Like an explicitly situations, I can imagine handling many different
environments to connect to and changing, not just OAuth config, but all
the configurations related to libpq on mixed different configurations,
even different authentication methods.

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

Well, I think I was misunderstood here, when I was talking about "debug
levels" I was talking about logs debug levels, now, disabling the
encryption, I'm guessing you mean HTTPS vs HTTP, if that's the case,
well, that should be controlled by the user when setting the endpoint,
I don't think it's something that should be controlled in another way
than just the endpoint protocol.

Now I'm confused about what we talk about when we write "debug level",
can you clarify what does it mean to you?

Regards!