On Mon, Nov 3, 2025 at 8:53 AM Zsolt Parragi <[email protected]> wrote:
> On Mon, Nov 3, 2025 at 4:25 PM Jacob Champion
> <[email protected]> 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
