MIME-Version: 1.0
References: <16a91d02795cb991963326a902afa764e4d721db.camel@gmail.com>
 <3D82D240-1CC5-4CE6-BE30-6065B693D40C@yesql.se>
 <CAOYmi+=fbZNJSkHVci=GpR8XPYObK=H+2ERRha0LDTS+ifsWnw@mail.gmail.com>
 <CAN4CZFPhm2NCRWzZpX=kRLqyxu4Ps-d0xE5W75a-iDoKrLbXBw@mail.gmail.com>
In-Reply-To: 
 <CAN4CZFPhm2NCRWzZpX=kRLqyxu4Ps-d0xE5W75a-iDoKrLbXBw@mail.gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Wed, 19 Nov 2025 11:26:02 -0800
Message-ID: 
 <CAOYmi+=HcXJub1rDsQ7vpKMHuBB6NTA2Z5T=zAkaFdRThf+9zg@mail.gmail.com>
Subject: Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2B%3DHcXJub1rDsQ7vpKMHuBB6NTA2Z5T%3DzAkaFdRThf%2B9zg%40mail.gmail.com>
Precedence: bulk

On Mon, Nov 3, 2025 at 8:53=E2=80=AFAM Zsolt Parragi <zsolt.parragi@percona=
.com> wrote:
> On Mon, Nov 3, 2025 at 4:25=E2=80=AFPM 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=3Dhttp 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=3DUNSAFE-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=3DUNSAFE:http,trace,print-counts
    # these two are safe
    PGOAUTHDEBUG=3Dprint-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