Is there a reference that can be cited here to justify this parse? This needs some authority behind it.

Also, why not just use mbedtls's own API to determine both the "is psk" and "is recognised" question together?

const mbedtls_ssl_ciphersuite_t *info = mbedtls_ssl_ciphersuite_from_string(ciphername);
if (mbedtls_ssl_ciphersuite_uses_psk(info)) {
    ...

(With some extra bits to correctly handle the 'failed lookup' case, of course.)
(Assuming that special-casing PSK here is even the right design anyway.)

Why should PSK ciphers be singleton, rather than parsed and accumulated as part of the existing list code?

Why the intermediate self->psk_identity and self->psk_key variables? i.e. instead of a single function that combines the code with the code in ssl_socket_make_new to call mbedtls_ssl_conf_psk directly.

This condition should be more paranoid so it can give a better error. Mbedtls would error eventually, but any case where you don't have either all or none of those conditions, should be an error already.

These conversions could hit the bad_implicit_conversion path and bypass cleanup --- neither this method nor the setters for those variables actually check mp_obj_is_str_or_bytes.

Get the actual authoritative list of supported PSK suites by filtering the output from mbedtls_ssl_list_ciphersuites using mbedtls_ssl_ciphersuite_from_id and mbedtls_ssl_ciphersuite_uses_psk.

Redundant with the m_malloc_fail path already present in the allocator.

Redundant with the m_malloc_fail path already present in the allocator.

This path needs coverage, with test cases that set invalid keys and identites.

It's a pity the actual mbedtls_ssl_ciphersuite_uses_psk is only part of mbedtls/library/ssl_ciphersuites_internal.h header rather than a public include --- but IMO it's still better to just link against it anyway instead of re-implementing it. Just declare it yourself the same way its header does without defining it:

int mbedtls_ssl_ciphersuite_uses_psk(const mbedtls_ssl_ciphersuite_t *info);

If that's too spicy, add MBEDTLS_ALLOW_PRIVATE_ACCESS to mbedtls_config_common.h and examine the value of info->key_exchange against the four values it can have that indicate PSK suites.

Also, don't hardcode the numeric values, use the symbols! You can just id == MBEDTLS_TLS_PSK_WITH_NULL_SHA, you already even have the mbedtls/ssl_ciphersuites.h header that defines those.

Did ChatGPT write this? Because that's a lie:

These methods now configure PSK directly with mbedtls instead of storing values

The extra variables in mp_obj_ssl_context_t was a bit sub-optimal, but using shared static variables like this is completely unacceptable. Even if we ignore mutliple contexts clobbering each other, it's also a use-after-free bug. (Can you spot it? It's because BSS variables aren't visible to micropython's garbage collector unless you give them a root-pointer decorator. The key and identity values here could be eligible for collection the instant these functions return.)

The point of my earlier comment was this: The mp_obj_ssl_context_t object already has a place to store these values, in its contained mbedtls_ssl_config value --- i.e. the place that calling mbedtls_ssl_conf_psk stores them.
The API here should just be the thinnest possible veneer over that function to make it callable from micropython --- just a function that takes two string arguments, validates that they're strings, extracts the underlying string pointers, and calls mbedtls_ssl_conf_psk with them.