On Fri, Feb 27, 2026 at 10:57 AM Dmitry Dolgov <[email protected]> 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
