Re: Thoughts on a "global" client configuration?

On Thu, Oct 9, 2025 at 9:02 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I understand that, but you mentioned a few different settings ...
> which could hypothetically turn into changing the default for 1 of
> them every year or two.

I think we should avoid equating "we can change it more frequently
than never" with "we will break everyone all the time". A hypothetical
configuration file does not absolve us of our need to choose defaults
wisely and maintain good interoperability for the community.

> > I think that's how we get into situations like "everyone hates
> > sslmode=require but no one will change it." I'm looking to add a tool
> > to make agreement easier in the first place.
>
> That's a fair goal, but I'm not sure that I agree that the tool you're
> proposing actually has that effect.

And that's fair too; I don't expect to drive consensus without a
concrete proposal in hand.

> > (Maybe there's a better tool than a configuration file? But I'd like
> > to see what a file looks like, because I'm not familiar with any other
> > network client that requires you to put every setting into the URI you
> > use to contact the server. If you know of one please tell me so I can
> > study it.)
>
> That's a fair complaint, but on the other hand, specifying the use or
> non-use of TLS in the URI is completely normal. What's abnormal about
> our system is that (1) we've got all of these extra levels that don't
> exist for, say, HTTP and (2) our syntax is quite verbose.

This again tries to collapse the problem down to sslmode. Look at
gssencmode, sslnegotiation, sslrootcert: all things which IMHO do not
belong in the query string of a URI. We've put connection settings and
application settings at the same level, and to me, that's the abnormal
thing about our system. (Similar problem to the _pq_.* protocol option
debates, actually.)

When you tell your browser to adjust the meaning of "HTTPS" -- whether
it's adding a new root cert to the trust store, disallowing TLS 1.1,
etc. -- you generally do that in a different place from the URL bar,
and the "clients" making use of HTTPS URLs do not know about it. Our
relative fragmentation (when compared to the Web) probably puts us
closer to the SSH use case than a browser use case, because we
absolutely need per-host connection settings. But SSH still lets you
ratchet up defaults across all hosts with its ssh_config.

(I'm actually tempted to double down on the SSH comparison and say
that its host-matching configuration model might be an even _better_
fit for us than our opt-in services model. Because it'd allow every
libpq client to delegate the question of "how do I connect to X" to
us, if they wanted, without having to drill a service name through the
stack. I don't know how far I want to go down that path, in the
absence of people asking for it.)

> > I prefer simplicity, too, but environment variables for libpq mean
> > "this is a trusted setting that you should prefer to the default, even
> > if it's worse". That's not a good fit for the security-related
> > settings I'm concerned with changing.
>
> Can you expand on this thought? I don't think I understand. What makes
> the environment variables "trusted values that you should prefer to
> the default" rather than just "values that we want to use in this
> context"?

Sure: In the context of this thread, I want the configuration file to
be able to act as a pressure release valve for admins who absolutely
cannot follow us forward into verify-full by default, by allowing them
to return to the previous behavior. But setting a new environment
variable isn't guaranteed to return to the previous behavior, because
it's reasonable for applications to defer to trusted envvars if
they're set. (Think `${PGSSLMODE:-verify-full}`.)

In the case of PGSSLMODE=prefer, I think that's especially dangerous:
it will always _look_ like things have returned to the previous state,
because everything will still be requesting SSL, but you may have
actively downgraded the security of the application.

The worst-case persona, in my mind, is a new sysadmin who's panicking
because of a libpq5 upgrade in production on Debian, say maybe through
an indirect package dependency, and something has started failing that
wasn't caught in testing. Downgrading means losing whatever package
brought in the dependency, and they're definitely not equipped to
audit all their code to make sure that PGSSLMODE=prefer isn't going to
do something horrible. I want to give that sysadmin a safe way out.

--Jacob