Re: Thoughts on a "global" client configuration? - Mailing list pgsql-hackers

On Mon, Oct 13, 2025 at 1:15 PM Robert Haas <robertmhaas@gmail.com> wrote:
> The distinction in my mind is that sslmode, gssencmode, and
> sslnegotiation define what we're doing on the wire, whereas parameters
> like sslcert just define where local resources are to be found.
> Granted, that influences what we're doing on the wire in a different
> way, but you can move the file and update the value of sslcert and get
> the same results, because the connection fundamentally doesn't care
> where its local files are found, whereas flipping sslnegotiation or
> sslmode is a fundamental alteration to what the connection tries to
> do. How do you see it?

I agree with your bucketing of wire-vs-non-wire parameters, but to me,
that's not really the dividing line for what belongs in an "ideal"
connection string. It's just an indication that something is off --
that there is no dividing line right now, and that's strange.

I've been trying to frame this in terms of our URI structure, mostly
because it highlights how odd our setup is. It's true that you don't
type your client certificate path into your browser's location bar
(it's not on the wire), but it's also true that you don't put the
minimum TLS version there, or the OCSP fallback behavior (both on the
wire). The latter two are still out-of-band decisions, separate from
the name of the resource itself, even though they directly affect
whether a browser can connect at all to certain hosts.

That goes back to what I was saying earlier about ssh_config, and how
its style might have been a better match for some of our use cases.
Host matching lets the user say "oh yeah, that server is weird,
connect this way" without forcing every application that uses SSH to
understand that information.

> I'm unconvinced that this is worth worrying about. I am a little
> surprised to see the number of hits that your search found, but I
> think people will (and should) update their code.

I think one of the fundamental issues with sslmode=prefer is that the
affected people are unlikely to notice they should update their code.
SSL will continue to be used. Nothing will break, but active attacks
will be silently enabled. And if someone affected by this comes to a
list to report and/or complain, I think they're likely to be greeted
by a chorus of "why would an informed sysadmin ever define
PGSSLMODE=prefer? so insecure, PEBKAC, skill issue".

I get that I'm coming at this from the paranoid-security-person side
of things, but I feel like the ecosystem effects of officially
recommending a bad PGSSLMODE as a compatibility hack are not being
given the same scrutiny as the ecosystem effects of adding a
configuration file.

> My theory is that they'll be even less impressed if they try to use a
> supposedly-compatible library and it breaks a bunch of stuff

I agree with that, but also that's why I started this thread. I think
both options (keeping sslmode=prefer by default, and unilaterally
changing to something stronger) are untenable, and I'm trying to cut
the knot.

Some library I was looking at recently (can't remember which, or I'd
link it) had an interesting approach to compatibility breaks. It
1) warned about the break in version X, if you relied on the behavior,
2) broke behavior by default in version X+1, but gave you the option
to return to the prior functionality for a single release, and then
3) removed the deprecated behavior in version X+2.

I don't think that exact plan would work for us, but if our back
branches had client config files, you might imagine a world where we
backported warnings for really important changes. "You're relying on
default behavior that is about to change in PG30, and you need to
explicitly opt into the old behavior now if you don't want to break
when you upgrade."

(Proof-of-concept on the way soon.)

Thanks,
--Jacob