> On Mon, Aug 31, 2026 at 09:37:39AM -0700, Si, Evan wrote:
>
> Assuming we still want to keep those details, I feel the naming could be a
> bit clearer. "supported_groups" makes sense in the context of the handshake,
> but having the server tell a client a value is "supported" feels like its
> saying something about itself rather than the client. Maybe
> "client_supported" is more informative?
Fair enough. It's already described in the documentation as "groups
supported by the client", but yeah, still could be confusing and a more
verbose column name can help.
> Regardless, if RSA key exchange is used, SSL_get_negotiated_group is
> supposed to return NID_undef. Things will error (Openssl 3.5 example):
Interesting, good to know, thanks. After a quick look I couldn't find
any documentation as to why it's happening this way, I only see OpenSSL
returning NID_undef if using tls1.2 and the ssl state has no session. Is
there any explanation?
In any case that gives a new spin to what Cary was mentioning few
messages above. If we have a valid use case where there is no negotiated
group, then SRF has to return NULL for those rows. To still have a nice
looking ssl_group_info function, I'll create another one called
ssl_group_info_with_nulls, so that ssl_group_info would be a wrapper
around it to filter out nulls.
As an interesting side note, I was looking at the possible error codes
for a warning in this scenario, and stumbled upon one called
ERRCODE_WARNING_NULL_VALUE_ELIMINATED_IN_SET_FUNCTION
which seems to be never used, maybe it's worth removing it.
