On Mon, Nov 3, 2025 at 6:24 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> If we do allow this (IIRC we did discuss during development to allow this but
> erred on the side of caution)
Yeah, the replaced comment explains it. The assumption is that
whatever device you're using to log in (presumably a browser, not
Curl) has to have the certificates figured out for production use, so
overriding it for Curl alone is probably only good enough for dev use.
But I ran into this annoyance (wanted to override the CA for temporary
development purposes, got sprayed with debug output) during a demo
just last month, so I'm in favor of doing something to make this
easier.
> it should probably be made into a env var *and*
> connection param setting like how libpq is otherwise configured?
I'm still not quite sure about the target audience. If it's just for
developers, I don't necessarily see a need to take up connection
string space (or provide our proxies with yet another setting to worry
about).
Jonathan, the patch itself claims to handle two cases. What's the
production use case where a company has its own CA isolated from the
Internet but isn't willing to add that CA to the system trust?
The reason I ask is that we'd briefly talked about splitting
PGOAUTHDEBUG into more granular settings than just "off" and "UNSAFE".
So if this is a developer-only thing, we could maybe put some more
design work into the list of debug features. That list currently
includes the stderr spray, turning off HTTPS, allowing sub-second ping
intervals, overriding the CA, debugging libpq-oauth link failures,
counting the calls to the flow -- all of which run the gamut from
"completely unsafe" to "completely safe".
Thanks!
--Jacob
