Thread

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

Jacob Champion <jacob.champion@enterprisedb.com> — 2025-12-16T18:48:18Z

On Fri, Dec 12, 2025 at 3:05 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> I implemented a simple patch based on the above suggestion
> (PGOAUTHDEBUG=UNSAFE:http...).

Thank you!

> I added the new functions into a common source file which gets
> included in both the oauth module and libpq. I'm not entirely happy
> about this, but I didn't see a better way without duplicating the
> code.

Yeah, I'm not entirely happy about it either. Let me think about some
alternatives... pgcommon is a possibility, as is reworking the API so
that it's more ephemeral (these probably don't need to be super
performant, so an `inline static` header implementation that reparses
the envvar each time might work).

> My concern,  which is also there with the current version: is an
> environment variable the best way to control these settings in a
> library included into many applications? Wouldn't it be better to make
> these settings in libpq (or the oauth module), and only add the
> environment variables to psql?

1) Do you plan to be setting debug variables in production?
2) Do you want these settings to be part of a postgres:// URI?

For me the answer to both is "no", so I'm not too excited about adding
these as libpq connection parameters. Did you have another idea in
mind?

> This can be used to inject a CA into an application without the user
> noticing it,

I don't disagree. But at this point in these conversations, the
question posed is typically "is the new risk/reward tradeoff any worse
than PGSSLROOTCERT or PGSSLMODE or PGSERVICEFILE (or LD_LIBRARY_PATH
or PATH)?" I'd say no, not enough to introduce a new way of
configuring things for this particular setting.

I've argued in the other direction before [1], but I still feel good
about that, because I think a global keylogfile is more sensitive than
this.

> or without the application developer being aware of the
> possibility.

Mmm... I'd say that application developers always have to be aware of
user environment changes in the context of any Linux programming, let
alone libpq client development. The user is generally in partial
control of the linker. Nearly every libpq setting is accessible via
the environment. (setuid programming is its own specialized skillset
for a reason.)

Now, if there's any appetite to make the situation better, continuing
to add security-critical settings into the environment makes things
worse for anyone who wants to propose an alternative. But that's where
we stood as of the last related conversation I was involved in.

> But by splitting the setting into multiple flags,
> this can go unnoticed even in a console application.

Because it's not obviously spraying output all the time, you mean? We
could perhaps be noisier when any UNSAFE setting is in use.

> Another question is what to do with the CA file - currently it remains
> a separate (environment) variable, but maybe it could be included in
> the option string instead:
> PGOAUTHDEBUG=UNSAFE:custom-ca=/path/to/the/file

I think I've been convinced by the existence of this thread that we
should split PGOAUTHCAFILE out of debug options entirely, pending the
resolution of some of the open questions.

Thanks,
--Jacob

[1] https://postgr.es/m/CAOYmi%2BmY7zBXTqJT6EYP_6sdk7ro8L8ByToKb4f-hU5qnpOxhw%40mail.gmail.com