According to the docs, group_name may return NULL in case of an error. Maybe check that there isn't an error?

Note 2: the docs only mentions the case when the TLS session wasn't established yet, but to be on the safe side, I'd prefer checking if there's an error on OpenSSL's side.

Are you suggesting adding a unit test here which verifies that OpenSSL returning NULL will hit this code and return None, or are you thinking this should return an error instead?

Right now, this API matches the behavior of SSLSocket.cipher(), returning None when a TLS session is not established (either because of an error or because the application queries this information too early, before the handshake is performed). If there is an error during the handshake, I would expect that to have already raised an error to the calling code. This check is just to handle if the calling code decides to try and query the group despite the incomplete handshake.

Ah no, I'm just telling to check that we don't have an SSL error set before returning None. If there is an SSL error, we can raise an exception. Otherwise, you can return None as you did.

Looking at the documentation, I can see where you'd think SSL_get0_group_name() might set an SSL error before returning NULL. Looking at the implementation, though, the functions called by SSL_get0_group_name() return NULL without actually ever setting an error themselves. They just check if other state is NULL or not, and return the name if one is available. I think the error referred to in the docs would have been returned in a prior call, such as when initiating the handshake.

I could put in an explicit call to ERR_get_error here, but I can't find any other code in this module which looks at that to decide whether to return an error. There's always a check for a special error return value in the function before looking at any SSL error information.

In this case, since NULL is returned without setting an SSL error, I would recommend we treat all NULL values as indicating the handshake didn't complete or wasn't attempted yet, and always return None for both cipher and group (and eventually sigalgs when that support is added).

In this case, since NULL is returned without setting an SSL error

Ah, so it would be hard to detect it. Ok, we can return None, and anyway, if there's an issue, subsequent calls to the interface will fail I think.

I would recommend we treat all NULL values as indicating the handshake didn't complete or wasn't attempted yet,

That could be more useful for the user. Can you make some test for that (namely, you set a group, and try to get its name even though the session doesn't exist and see that it returns None). We should also document that it returns None if no session exists yet.

The doc about returning None is already in place:

.. method:: SSLSocket.group()

   Return the group used for doing key agreement on this connection. If no
   connection has been established, returns ``None``.

   .. versionadded:: next

This is very similar to the docs for SSLSocket.cipher().

I should be able to come up with a unit test which creates an SSLSocket without connecting it and then tries to query the group - working on that now.

Trying to get an SSLSocket created without an underlying connection is actually somewhat messy. I think a more realistic case would actually be to try and query the cipher & group after a handshake failure, like no matching ciphers between the client and server. There's already a test for that, and it's straightforward to add in checks that both cipher() and group() return None in that case. Checking that in momentarily.