Re: Thoughts on a "global" client configuration?

On Mon, Oct 13, 2025 at 3:57 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> 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.

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

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

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, but I
wonder what Christoph Berg (cc'd) thinks.

--
Robert Haas
EDB: http://www.enterprisedb.com