Обсуждение: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode

Hi,

While working on a validator for keycloak[1] with libpq-oauth I find
out that to allow a self-signed certificated I had to set the CA on the
client but for this was required to also set the PGOAUTHDEBUG=UNSAFE
which generated a lot of information on the client side that I didn't
need for my testing and work.

This patch basically remove the need of setting the PGOAUTHDEBUG=UNSAFE
to be able to use PGOAUTHCAFILE.

I'm not sure if where I put the documentation is the right place, I
would like to have some opinions on that matter too.


[1] https://github.com/cloudnative-pg/postgres-keycloak-oauth-validator

--
Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>

> On 29 Oct 2025, at 20:19, Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> wrote:

> This patch basically remove the need of setting the PGOAUTHDEBUG=UNSAFE
> to be able to use PGOAUTHCAFILE.

If we do allow this (IIRC we did discuss during development to allow this but
erred on the side of caution) it should probably be made into a env var *and*
connection param setting like how libpq is otherwise configured?

--
Daniel Gustafsson

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

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

Hi!
On Mon, 2025-11-03 at 08:24 -0800, Jacob Champion wrote:
>
> 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.

I was creating some demo too, at the beginning was really useful, but
after some seconds, I used to lose the URL and the code, the URL wasn't
an issue later, but the code it was.

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

Well, there's a couple of cases, I figure out after the first email,
thanks to Alvaro, that I wasn't clear in the comments, probably I
should change it, will try to describe a few cases that I've seen over
the years.

* In Kubernetes, even with a network isolation, people use to prefer
having TLS connections, just because it's the standard, but in internal
communications (between namespaces and pods), these domains contain the
format: <service>.<namespace>.svc.<clustername>.local, as you can
already imagine, this kind of domain cannot be verified by an external
CA, but they can be generated and verified with an internal CA. Now the
question is, why they  don't add this CA to every distribution? The
defacto standard way to do this in Kubernetes is to take the CA from a
ConfigMap or Secret (objects that can provide content inside the
infrastructure) and deploy this dynamically inside the Pod, so, to
indicate the path to this file, the standard is to use an environment
variable, in this case, if the content of the ConfigMap or Secret
changes, this will be refreshed inside the Pod too.

* Big companies like those managing credit cards or big banks, use to
have air gap environment, which may have exactly the same problem while
communicating internally, the CA cannot verify an internal domain, on
these cases the CA is usually moved around and installed in a specific
path and installed on specific path and not the system path (usually
because of compliant reasons), meaning that you will actually have to
provide with a variable/configuration/environment the path to the CA.

* Development cases, I think this is clear, but even when you're doing
development, you'll be using a self-signed certificate, but doing
developing and losing URL and the code it can be really common, it
happened to me many times and it wasn't nice looking for the code.

* CI cases, here, you'll not have time to get a certificate to just
trigger an action against a one time domain, usually with a random
domain to not conflict with other CI running at the same time, and you
should never expose sensitive information on the CI output like the one
exposes when enabling PGOAUTHDEBUG="UNSAFE"


> The reason I ask is that we'd briefly talked about splitting
> PGOAUTHDEBUG into more granular settings than just "off" and
> "UNSAFE".

I was thinking the same for another patch that will require discussion
for sure, but it's something similar to add some levels of debug, for
example, when you want to have the tokens or when you only want to see
the URLs used to negotiate (which are really useful when working with
the OAuth flows) or the deep one when you want to see the tokens.

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

Ho! where can I see this list? I'd love to help with something here!

I'm more than open to keep discussing this, because I can see that many
people will be affected by the same, specially in the Kubernetes world.

Thank your for looking at this!

--
Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>

> On 4 Nov 2025, at 14:00, Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> wrote:

> Ho! where can I see this list? I'd love to help with something here!

There is no documented list as far as I can remember, but look for calls to
oauth_unsafe_debugging_enabled() in:

https://github.com/postgres/postgres/blob/master/src/interfaces/libpq/fe-auth-oauth.c

And conditionals checking the actx->debugging variable in:

https://github.com/postgres/postgres/blob/master/src/interfaces/libpq-oauth/oauth-curl.c

--
Daniel Gustafsson

On Tue, Nov 4, 2025 at 5:02 AM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> wrote:
> * In Kubernetes, even with a network isolation, people use to prefer
> having TLS connections, just because it's the standard, but in internal
> communications (between namespaces and pods), these domains contain the
> format: <service>.<namespace>.svc.<clustername>.local, as you can
> already imagine, this kind of domain cannot be verified by an external
> CA, but they can be generated and verified with an internal CA. Now the
> question is, why they  don't add this CA to every distribution? The
> defacto standard way to do this in Kubernetes is to take the CA from a
> ConfigMap or Secret (objects that can provide content inside the
> infrastructure) and deploy this dynamically inside the Pod, so, to
> indicate the path to this file, the standard is to use an environment
> variable, in this case, if the content of the ConfigMap or Secret
> changes, this will be refreshed inside the Pod too.

Okay, that's good to know. But I'm still missing how the end user (a
human) trusts that magic CA within the browser or device they use to
finish the actual flow?

> * Big companies like those managing credit cards or big banks, use to
> have air gap environment, which may have exactly the same problem while
> communicating internally, the CA cannot verify an internal domain, on
> these cases the CA is usually moved around and installed in a specific
> path and installed on specific path and not the system path (usually
> because of compliant reasons), meaning that you will actually have to
> provide with a variable/configuration/environment the path to the CA.

Same question as above, but I'm slowly being convinced that this
thread needs to remain separate from the PGOAUTHDEBUG split
discussion, even if they're related.

This might be a silly-small example, but I've added a stub spec:

    https://wiki.postgresql.org/wiki/Proposal:_Promote_PGOAUTHCAFILE_to_feature

> * Development cases, I think this is clear, but even when you're doing
> development, you'll be using a self-signed certificate, but doing
> developing and losing URL and the code it can be really common, it
> happened to me many times and it wasn't nice looking for the code.

Right.

> * CI cases, here, you'll not have time to get a certificate to just
> trigger an action against a one time domain, usually with a random
> domain to not conflict with other CI running at the same time, and you
> should never expose sensitive information on the CI output like the one
> exposes when enabling PGOAUTHDEBUG="UNSAFE"

Who's running the CI, and how do OAuth and Device Authorization factor
into it? (And why would a human user be okay with feeding their
privileges into an authorization server with a random-looking host
name every time they run it?)

> > The reason I ask is that we'd briefly talked about splitting
> > PGOAUTHDEBUG into more granular settings than just "off" and
> > "UNSAFE".
>
> I was thinking the same for another patch that will require discussion
> for sure, but it's something similar to add some levels of debug, for
> example, when you want to have the tokens or when you only want to see
> the URLs used to negotiate (which are really useful when working with
> the OAuth flows) or the deep one when you want to see the tokens.

I think that's reached critical mass, then.

> Thank your for looking at this!

Thanks for the discussion!

--Jacob

On Mon, Nov 3, 2025 at 8:53 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> On Mon, Nov 3, 2025 at 4:25 PM 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=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

Hello

I implemented a simple patch based on the above suggestion
(PGOAUTHDEBUG=UNSAFE:http...). I did not update the documentation yet,
let's see what everyone thinks about it before that, and I also have
some concerns/questions.

I added the new functions into a common source file which gets
included in both the oauth module and libpq. I'm not entirely happy
about this, but I didn't see a better way without duplicating the
code.

My concern,  which is also there with the current version: is an
environment variable the best way to control these settings in a
library included into many applications? Wouldn't it be better to make
these settings in libpq (or the oauth module), and only add the
environment variables to psql?

This can be used to inject a CA into an application without the user
noticing it, or without the application developer being aware of the
possibility. With the current single-value variable, it is already
possible, and in an application without a visible standard output, it
is already hidden. But by splitting the setting into multiple flags,
this can go unnoticed even in a console application.

Another question is what to do with the CA file - currently it remains
a separate (environment) variable, but maybe it could be included in
the option string instead:
PGOAUTHDEBUG=UNSAFE:custom-ca=/path/to/the/file

What do you think about it?

Hi!

Sorry for the delayed answer!

>
> Okay, that's good to know. But I'm still missing how the end user (a
> human) trusts that magic CA within the browser or device they use to
> finish the actual flow?

More than the end user "trusting" a "magic" CA, it's about what company
will tell you to use a CA, most of the time you don't have option as a
developer or even as a sysadmin since these kind of things are coming
strictly from InfoSec departments or are just some instruction to
accomplish some certification like ISO9001 or ISO27001, which for
isolated environments are required to be CA managed internally, and
must of the times the users may not see this CA, this will be actually
pushed by another external application installed in the company
workstation like CrowdStrike does, I'm not saying this will be the
case, but it's an example of how companies work now days with the CA's

>
>
> Same question as above, but I'm slowly being convinced that this
> thread needs to remain separate from the PGOAUTHDEBUG split
> discussion, even if they're related.

Totally agree, now I'm thinking the same, it should be a feature
because there's more examples that I've been thinking about that may
require this to be even a bit more flexible, for example, when working
with edge computing, if you want (in the future because now it's not
possible, yet) authenticate a device against PostgreSQL it may require
to have that CA as a encoded string int he variable, not just as a
file, wild thought I know, but it may make sense

> This might be a silly-small example, but I've added a stub spec:
>
>    
> https://wiki.postgresql.org/wiki/Proposal:_Promote_PGOAUTHCAFILE_to_feature
>

How can we work on that? because of the above it may be required to add
even more possibilities.

>
>
> Who's running the CI, and how do OAuth and Device Authorization
> factor
> into it? (And why would a human user be okay with feeding their
> privileges into an authorization server with a random-looking host
> name every time they run it?)
>

With that I was thinking more in the future than what you can do now,
the OAuth flow provides many features that can be implemented in the
future and I was just looking ahead with the CI example.


> > > The reason I ask is that we'd briefly talked about splitting
> > > PGOAUTHDEBUG into more granular settings than just "off" and
> > > "UNSAFE".
> >
> > I was thinking the same for another patch that will require
> > discussion
> > for sure, but it's something similar to add some levels of debug,
> > for
> > example, when you want to have the tokens or when you only want to
> > see
> > the URLs used to negotiate (which are really useful when working
> > with
> > the OAuth flows) or the deep one when you want to see the tokens.
>
> I think that's reached critical mass, then.
>

More than happy to help with this!

--

Hi!

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

I will for sure try to avoid this kind of format with comma separated
options, this mainly because are really hard to parse and manage in an
automated way, and sometimes, are hard to read when there's too many
options, and at some point, there could be many options since the flows
can start getting really complicated.
Why not keep something with debug levels? Even if it sounds really
classic, for parsing reasons are really good.

Now, if what is required it's counts or HTTP calls, probably this could
be like a "flow debug" an option like "PGOAUTHFLOWDEBUG" that depending
on the levels (info, debug, trace) can print from the hosts and/or url
calls, to the headers sent and received from the hosts.

The debug of a flow can be an entire set of levels due to the current
complexity and that may or may not increase in time, what do you think?

On Fri, Dec 12, 2025 at 3:05 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> I implemented a simple patch based on the above suggestion
> (PGOAUTHDEBUG=UNSAFE:http...).

Thank you!

> I added the new functions into a common source file which gets
> included in both the oauth module and libpq. I'm not entirely happy
> about this, but I didn't see a better way without duplicating the
> code.

Yeah, I'm not entirely happy about it either. Let me think about some
alternatives... pgcommon is a possibility, as is reworking the API so
that it's more ephemeral (these probably don't need to be super
performant, so an `inline static` header implementation that reparses
the envvar each time might work).

> My concern,  which is also there with the current version: is an
> environment variable the best way to control these settings in a
> library included into many applications? Wouldn't it be better to make
> these settings in libpq (or the oauth module), and only add the
> environment variables to psql?

1) Do you plan to be setting debug variables in production?
2) Do you want these settings to be part of a postgres:// URI?

For me the answer to both is "no", so I'm not too excited about adding
these as libpq connection parameters. Did you have another idea in
mind?

> This can be used to inject a CA into an application without the user
> noticing it,

I don't disagree. But at this point in these conversations, the
question posed is typically "is the new risk/reward tradeoff any worse
than PGSSLROOTCERT or PGSSLMODE or PGSERVICEFILE (or LD_LIBRARY_PATH
or PATH)?" I'd say no, not enough to introduce a new way of
configuring things for this particular setting.

I've argued in the other direction before [1], but I still feel good
about that, because I think a global keylogfile is more sensitive than
this.

> or without the application developer being aware of the
> possibility.

Mmm... I'd say that application developers always have to be aware of
user environment changes in the context of any Linux programming, let
alone libpq client development. The user is generally in partial
control of the linker. Nearly every libpq setting is accessible via
the environment. (setuid programming is its own specialized skillset
for a reason.)

Now, if there's any appetite to make the situation better, continuing
to add security-critical settings into the environment makes things
worse for anyone who wants to propose an alternative. But that's where
we stood as of the last related conversation I was involved in.

> But by splitting the setting into multiple flags,
> this can go unnoticed even in a console application.

Because it's not obviously spraying output all the time, you mean? We
could perhaps be noisier when any UNSAFE setting is in use.

> Another question is what to do with the CA file - currently it remains
> a separate (environment) variable, but maybe it could be included in
> the option string instead:
> PGOAUTHDEBUG=UNSAFE:custom-ca=/path/to/the/file

I think I've been convinced by the existence of this thread that we
should split PGOAUTHCAFILE out of debug options entirely, pending the
resolution of some of the open questions.

Thanks,
--Jacob

[1] https://postgr.es/m/CAOYmi%2BmY7zBXTqJT6EYP_6sdk7ro8L8ByToKb4f-hU5qnpOxhw%40mail.gmail.com

On Sun, Dec 14, 2025 at 3:13 AM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> wrote:
> > Okay, that's good to know. But I'm still missing how the end user (a
> > human) trusts that magic CA within the browser or device they use to
> > finish the actual flow?
>
> More than the end user "trusting" a "magic" CA, it's about what company
> will tell you to use a CA

Sure, but my question isn't about the trust model. Just to confirm:
you're saying that it's common for enterprise provisioning apps
(CrowdStrike et al) to push CAs directly into a browser trust store,
but _not_ to the system trust paths?

> Totally agree, now I'm thinking the same, it should be a feature
> because there's more examples that I've been thinking about that may
> require this to be even a bit more flexible, for example, when working
> with edge computing, if you want (in the future because now it's not
> possible, yet) authenticate a device against PostgreSQL it may require
> to have that CA as a encoded string int he variable, not just as a
> file, wild thought I know, but it may make sense

I think we want to keep these on disk; no reason to run up against
resource limits on the environment.

> > https://wiki.postgresql.org/wiki/Proposal:_Promote_PGOAUTHCAFILE_to_feature
>
> How can we work on that? because of the above it may be required to add
> even more possibilities.

Not sure what you mean. I think we're working on it now, in this thread?

On Sun, Dec 14, 2025 at 3:17 AM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> wrote:
> I will for sure try to avoid this kind of format with comma separated
> options, this mainly because are really hard to parse and manage in an
> automated way

I feel _very_ strongly that the "debug" options are for people.
Specifically developers who are debugging. What use case do you have
for automation and parsing outside of libpq?

> and sometimes, are hard to read when there's too many
> options, and at some point, there could be many options since the flows
> can start getting really complicated.

Can you explain more about what kinds of use cases would lead to
option explosion? When I'm developing I typically want to export an
interesting group of options once, and then not think about it for a
while. When debugging in production I typically want one particular
thing at a time.

> Why not keep something with debug levels? Even if it sounds really
> classic, for parsing reasons are really good.

I would say: because there's no natural order to the settings. It's a
bunch of on/off behaviors, some of which are safety-critical. What is
the "debug level" of disabling encryption compared to the debug level
of printing secrets or turning off parameter validation?

--Jacob

> I don't disagree. But at this point in these conversations, the
> question posed is typically "is the new risk/reward tradeoff any worse
> than PGSSLROOTCERT or PGSSLMODE or PGSERVICEFILE (or LD_LIBRARY_PATH
> or PATH)?" I'd say no, not enough to introduce a new way of
> configuring things for this particular setting.

Those are also bad, but there are also parameter alternatives for all of them.

> 2) Do you want these settings to be part of a postgres:// URI?

Not for debug settings, but if everyone agrees on splitting the CA
into its own setting, it could behave the same way as
sslrootcert/PGSSLROOTCERT.

> Because it's not obviously spraying output all the time, you mean? We
> could perhaps be noisier when any UNSAFE setting is in use.

Yes, mainly that. And as you mentioned there's already existing
behavior like that in the code, so it's nothing new.

> Yeah, I'm not entirely happy about it either. Let me think about some
> alternatives...

I'll try these suggestions and see what they look like - and I'll
start a separate thread with it so that this thread can focus on the
CA variable.

> Mmm... I'd say that application developers always have to be aware of
> user environment changes in the context of any Linux programming, let
> alone libpq client development. The user is generally in partial
> control of the linker. Nearly every libpq setting is accessible via
> the environment. (setuid programming is its own specialized skillset
> for a reason.)

My concern is not somebody developing libpq directly on Linux, but
more complex situations.

For example:

1. there is libpq
2. libpq is used by scripting language bindings for python/ruby/etc
3. language libraries are used in ORM frameworks, which have their own
configuration interface
4. ORM frameworks are used in web frameworks / other libraries
5. those frameworks/libraries get used by somebody writing an actual
webpage/application
6. And that webpage/application gets installed/maintained by an
administrator/user, who might or might not be aware of this

And we also have Windows/other platforms, where environment variables
are less visible.

> Now, if there's any appetite to make the situation better, continuing
> to add security-critical settings into the environment makes things
> worse for anyone who wants to propose an alternative

This is also probably a separate discussion, but what do you think
about introducing a parameter that disables environment variable
fallbacks? Both for existing variables like PGSSLROOTCERT and
new/debug variables like PGOAUTHCAFILE. (by default everything works
as currently; when specified environment variables are ignored)

On Wed, Dec 17, 2025 at 5:15 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> > I don't disagree. But at this point in these conversations, the
> > question posed is typically "is the new risk/reward tradeoff any worse
> > than PGSSLROOTCERT or PGSSLMODE or PGSERVICEFILE (or LD_LIBRARY_PATH
> > or PATH)?" I'd say no, not enough to introduce a new way of
> > configuring things for this particular setting.
>
> Those are also bad, but there are also parameter alternatives for all of them.

But if the concern is security, the existence of the parameter
alternatives doesn't really seem to help you.

> > 2) Do you want these settings to be part of a postgres:// URI?
>
> Not for debug settings, but if everyone agrees on splitting the CA
> into its own setting, it could behave the same way as
> sslrootcert/PGSSLROOTCERT.

I don't know if everyone does, but I've seen no pushback yet, so I
plan to do so (parameter + envvar).

I only nested it under debug settings because I thought there was no
production use case, and now that Jonathan is saying "yes, I have a
production case", that seems good enough. I don't think I need to
raise the bar any more than that.

> > Mmm... I'd say that application developers always have to be aware of
> > user environment changes in the context of any Linux programming, let
> > alone libpq client development. The user is generally in partial
> > control of the linker. Nearly every libpq setting is accessible via
> > the environment. (setuid programming is its own specialized skillset
> > for a reason.)
>
> My concern is not somebody developing libpq directly on Linux, but
> more complex situations.

Understood (and I'd like to make this better too). But see below.

> This is also probably a separate discussion, but what do you think
> about introducing a parameter that disables environment variable
> fallbacks? Both for existing variables like PGSSLROOTCERT and
> new/debug variables like PGOAUTHCAFILE. (by default everything works
> as currently; when specified environment variables are ignored)

I like the idea of more application control over this, generally. I
think the concern that's been raised before, for example with the
superuser-can-do-too-much conversations, is: Piecemeal improvements,
without a consensus on the end goal, can paradoxically make things
less secure. Because now users have a harder time reasoning about the
system's behavior and designing for it. It's even worse if committers
can't reason about it and start working at cross purposes.

For example, if we lock down our envvars and then immediately farm
security-critical decisions out to Kerberos or Curl or PAM or etc.
which use their own envvars, in what cases is that better than telling
application developers that hey, you always need to be careful about
sanitizing your environment if you somehow don't trust it? I don't
really know (hand-wavy), and I think proposals would need to provide
good arguments in favor. Definitely a separate discussion.

Thanks,
--Jacob