| 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
| 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 |