Horton

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

Jacob Champion <jacob.champion@enterprisedb.com>

View thread
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, "Jonathan Gonzalez V." <jonathan.abdiel@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-19T19:26:02Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. libpq: Split PGOAUTHDEBUG=UNSAFE into multiple options

  2. libpq: Add oauth_ca_file option to change CAs without debugging

On Mon, Nov 3, 2025 at 8:53 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> On Mon, Nov 3, 2025 at 4:25 PM Jacob Champion
> <jacob.champion@enterprisedb.com> wrote:
> > The reason I ask is that we'd briefly talked about splitting
> > PGOAUTHDEBUG into more granular settings than just "off" and "UNSAFE".
>
> That's more similar to the direction I considered going,

I've added a stub summary for this, too:

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

> I was
> thinking about adding a PGOAUTHDEBUG=http option. That way there's no
> need for self signed certificates, and it's easier to explain to users
> that this just allows a less secure quick http setup.

I think it's important to keep unsafe options labelled as such, but I
agree this would be helpful.

I'm not sure if we have prior art for expressing bitflags in Postgres
envvars, other than maybe PGREQUIREAUTH. A comma-separated list would
be easy to do. We could name these things according to whether they're
unsafe or not, like

    PGOAUTHDEBUG=UNSAFE-http,UNSAFE-trace,print-counts

Or maybe that's too verbose, and we could say that to use any of the
unsafe options, you have to say it up front:

    # http and trace are dangerous
    PGOAUTHDEBUG=UNSAFE:http,trace,print-counts
    # these two are safe
    PGOAUTHDEBUG=print-counts,print-plugin-errors

Or something else? Since this is developer-facing, I don't think it
has to necessarily be intuitive for end users, as long as the lack of
safety remains obvious to them. We can just focus on ergonomics for
us.

Thanks,
--Jacob