Re: Add ssl_(supported|shared)_groups to sslinfo

On Fri, Feb 27, 2026 at 10:57 AM Dmitry Dolgov <9erthalion6(at)gmail(dot)com> 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