Re: Thoughts on a "global" client configuration?

On Fri, Oct 10, 2025 at 6:24 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> That's a really interesting observation. I've always found it a bit
> odd that we put things like sslca and sslrootcert into the connection
> string, so I think you have a point, here. Not sure I agree about
> sslnegotiation or gssencmode, though -- those seem more like sslmode,
> which I would argue does belong in the connection string.

I could see gssencmode=require as a separate scheme. I still object to
its being a query string parameter; I don't think our current
acceptance of "gssencmode=require sslmode=require" is a particularly
good thing.

Putting sslnegotiation at the same level, though, feels like the
ancient distinction between "sldap" (STARTTLS) and "ldaps" (implicit
TLS), which IMO was a confusing historical mistake. And HTTP's version
of sslmode=prefer (opportunistic encryption, a dead experiment) was
still part of the `http:` scheme. Clients didn't opt into that via
URL; they configured it out of band.

> > 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}`.)
>
> I think this is aiming at quite a narrow target.

I agree. But it does exist in the wild [1], and sslmode is one of our
most important security settings. So I'm pretty worried about
unilaterally switching to a stronger default, without giving people a
tool to navigate it, if that would actually result in much weaker
security for some percentage of users.

> > 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.
>
> I would argue that this is a sign that calling every version libpq5 no
> matter how much we've changed the behavior is completely insane.

I think SONAME is the wrong hammer to reach for. Network compatibility
is more subtle than link-time ABI. But this has come up before, so I
want to explore it a bit. My guesses:

If we were to update to libpq.so.6 because of this -- without any
actual ABI changes -- then many people downstream aren't going to know
that they're opting into the new behavior anyway. For a true opt-in,
we'd need to actively break people at build time (libpq6.so.0?). Then
those people downstream will want to ask what amazing changes they've
gotten in exchange for this ecosystem fracture, and I suspect they'd
be less than impressed if we said "it makes sslmode stronger by
default".

Our maintainers will probably be less than impressed as well, now that
they get to keep two separate side-by-side binaries that are 99.999%
identical. (And I think there are dependency diamond problems, unless
we version all our symbols, but I haven't paid attention to modern
practices there.)

Maybe the least impressed will be any middleware maintainers who get
their connection strings from a layer above them. We're asking them to
opt into the new behavior at build time, but they can't know whether
it's safe, either. For them, it's _still_ a user-level decision; all
we've done is kicked the can, and nothing has actually improved.

All this to say, I think libpq6 should happen because of an ABI change
relevant to the code that links against us, not because of a user
compatibility change.

> This
> scenario gets a whole lot better if installing a new release of
> PostgreSQL that behaves differently doesn't magically change the
> behavior of any existing releases that are already installed.

We could probably do that if we really wanted, without breaking
SONAME. Our server already has its extensions tell it what version
they were compiled against, and our client could similarly use macro
tricks. Or symbol versioning.

But, as above, I still don't think that an opt-in at build time can
fix the general problem. It only delays the pain until the next time a
dependent package is built.

> At the risk of repeating myself, I also think that we need to consider
> the flip side of this scenario: some system administrator who thinks
> they know better throws something into a system-wide configuration
> file and breaks things for, say, PostgreSQL developers running the
> regression tests

(this is solved, though)

> or applications running on the machine that assume a
> certain system-wide configuration that in reality need not prevail
> everywhere.

I agree we need to consider this scenario; I'm just finding it hard to
treat it as anything other than "don't do that then, highly-privileged
system administrator!" I assume we would tell them the same thing
today if they exported PGSERVICE globally and broke applications that
relied on environment variables.

> I sometimes worry too much about non-problems at times,
> and this might be one of those times, so it would be good to hear from
> more people, but I think we need to be convinced not only that this
> proposal has enough upside to be worth pursuing but also that the
> downsides won't be too painful.

Agreed.

Thanks,
--Jacob

[1] https://github.com/search?q=%22PGSSLMODE%3A-require%22&type=code