I was thinking about asking something similar.
In our case, we have two problematic use cases: quick demo setups and CI.
When you start up a simple keycloak instance, you have two easy
options: either use http, or self-signed certificates.
For a CI setup, I can create disposable containers, generate
self-signed certificates, make the OS trust them, and run the tests
that way. But it's complex, and even if it were simple, it's not ideal
for a quick "how to set up a test environment" guide. I also
considered creating a demo docker-compose setup, but even with that, I
can't make the user's browser trust the certificates.
I also do not want to instruct users to specify this variable, as it
provides tons of debug output, some of that is sensitive tokens, and
the users might now know that.
> 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 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.
On Mon, Nov 3, 2025 at 4:25 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> 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
>
>