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

On Tue, Nov 4, 2025 at 5:02 AM Jonathan Gonzalez V.
<jonathan(dot)abdiel(at)gmail(dot)com> wrote:
> * In Kubernetes, even with a network isolation, people use to prefer
> having TLS connections, just because it's the standard, but in internal
> communications (between namespaces and pods), these domains contain the
> format: <service>.<namespace>.svc.<clustername>.local, as you can
> already imagine, this kind of domain cannot be verified by an external
> CA, but they can be generated and verified with an internal CA. Now the
> question is, why they don't add this CA to every distribution? The
> defacto standard way to do this in Kubernetes is to take the CA from a
> ConfigMap or Secret (objects that can provide content inside the
> infrastructure) and deploy this dynamically inside the Pod, so, to
> indicate the path to this file, the standard is to use an environment
> variable, in this case, if the content of the ConfigMap or Secret
> changes, this will be refreshed inside the Pod too.

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?

> * Big companies like those managing credit cards or big banks, use to
> have air gap environment, which may have exactly the same problem while
> communicating internally, the CA cannot verify an internal domain, on
> these cases the CA is usually moved around and installed in a specific
> path and installed on specific path and not the system path (usually
> because of compliant reasons), meaning that you will actually have to
> provide with a variable/configuration/environment the path to the CA.

Same question as above, but I'm slowly being convinced that this
thread needs to remain separate from the PGOAUTHDEBUG split
discussion, even if they're related.

This might be a silly-small example, but I've added a stub spec:

https://wiki.postgresql.org/wiki/Proposal:_Promote_PGOAUTHCAFILE_to_feature

> * Development cases, I think this is clear, but even when you're doing
> development, you'll be using a self-signed certificate, but doing
> developing and losing URL and the code it can be really common, it
> happened to me many times and it wasn't nice looking for the code.

Right.

> * CI cases, here, you'll not have time to get a certificate to just
> trigger an action against a one time domain, usually with a random
> domain to not conflict with other CI running at the same time, and you
> should never expose sensitive information on the CI output like the one
> exposes when enabling PGOAUTHDEBUG="UNSAFE"

Who's running the CI, and how do OAuth and Device Authorization factor
into it? (And why would a human user be okay with feeding their
privileges into an authorization server with a random-looking host
name every time they run it?)

> > The reason I ask is that we'd briefly talked about splitting
> > PGOAUTHDEBUG into more granular settings than just "off" and
> > "UNSAFE".
>
> I was thinking the same for another patch that will require discussion
> for sure, but it's something similar to add some levels of debug, for
> example, when you want to have the tokens or when you only want to see
> the URLs used to negotiate (which are really useful when working with
> the OAuth flows) or the deep one when you want to see the tokens.

I think that's reached critical mass, then.

> Thank your for looking at this!

Thanks for the discussion!

--Jacob