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

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, "Jonathan Gonzalez V(dot)" <jonathan(dot)abdiel(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode
Date: 2025-11-19 19:26:02
Message-ID: CAOYmi+=HcXJub1rDsQ7vpKMHuBB6NTA2Z5T=zAkaFdRThf+9zg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 3, 2025 at 8:53 AM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> On Mon, Nov 3, 2025 at 4:25 PM Jacob Champion
> <jacob(dot)champion(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-11-19 19:35:11 Re: should we have a fast-path planning for OLTP starjoins?
Previous Message Robert Haas 2025-11-19 19:17:37 Re: Consistently use the XLogRecPtrIsInvalid() macro