MIME-Version: 1.0
References: <d57duqvzkxe43oons3jkdq7pj2wacidg7qorxommri74evu3l2@4x53she7mf77>
 <D1EC4B00-9593-488F-916D-090A73E69B4E@yesql.se> <CAOYmi+nkT7rkbNd6que0wtz=epOikgBKSDR88DQ=cyNJwiUw8Q@mail.gmail.com>
 <srua2tidoiztaytmxlwjfpjhntxelmxpfta4lhulvlker444yg@sf232zqm3qvs>
 <CAOYmi+k7v6hP5nM7BQdKu37TJFi-X=d7_SDswZBV5q0awxPVYg@mail.gmail.com> <qyw7l5ztbqouluctxgbxc2aty43suulka2q4ybpaew4tey7rlw@l66rjb7vxxhk>
In-Reply-To: <qyw7l5ztbqouluctxgbxc2aty43suulka2q4ybpaew4tey7rlw@l66rjb7vxxhk>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Fri, 27 Feb 2026 16:51:40 -0800
Message-ID: <CAOYmi+=r50Kk1c7A7O8yXwJzALyyqDmQE7FiCZvZmt_3WRBGwQ@mail.gmail.com>
Subject: Re: Add ssl_(supported|shared)_groups to sslinfo
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2B%3Dr50Kk1c7A7O8yXwJzALyyqDmQE7FiCZvZmt_3WRBGwQ%40mail.gmail.com>
Precedence: bulk

On Fri, Feb 27, 2026 at 10:57=E2=80=AFAM Dmitry Dolgov <9erthalion6@gmail.c=
om> wrote:
> I take it as an argument that
> expanding sslinfo goal and focus is not a problem, as long as it's
> clearly communicated and documented. What do you think?

Yeah -- as long as the API stays coherent, I have no issue with
expanding sslinfo's capabilities.

>     select * from ssl_group_info();
>         type    |        name
>     ------------+--------------------
>      negotiated | X25519MLKEM768
>      shared     | X25519MLKEM768
>      shared     | x25519
>      supported  | X25519MLKEM768
>      supported  | x25519

Hmm, I'm developing strong opinions over something I said I didn't
feel strongly about. Sorry...

The type names "negotiated", "shared" and "supported" don't really
tell me much as an end user. I know, as a dev, that "negotiated" is
the one that was chosen, "supported" is what the client provided, and
"shared" is the intersection of the client and server sets. But I
think it'd be good to choose names that are either based on the
official TLS specification, or immediately clear to someone who is not
well-versed in TLS to begin with, as opposed to using OpenSSL's
internal API names.

Also, I feel like this is still missing the server side of the Venn diagram=
.

Also also: if we later expose a version of this table for the
ciphersuites or other negotiated parameters, is this how we'd want the
table to look? What did you care most about when you were debugging?

--Jacob