Would you be open to adding a micropython-ssl package that wraps ussl, similarly to how micropython-socket wraps usocket? I can think of two use cases for this, as discussed below. I'd be happy to contribute the code for this, but I want to make sure it's something you'd be receptive to first, especially considering that it would be a new package.

Use case 1: Drop default arguments

According to the docs for most (or maybe all) ports, the signature for wrap_socket is ssl.wrap_socket(sock, server_side=False, keyfile=None, certfile=None, cert_reqs=CERT_NONE, ca_certs=None), with the caveat that

Depending on the underlying module implementation for a particular board, some or all keyword arguments above may be not supported.

Indeed, most ports (it seems) do not support nearly so many of these. On Unix, for example, even the keyfile and certfile arguments are not accepted.

Note though, that even ussl.wrap_socket(s, keyfile=None) does not work, even though it should be equivalent to ussl.wrap_socket(s). The proposed micropython-ssl package could provide an ssl.wrap_socket function that drops keyword arguments whose values are the default (i.e. ssl.wrap_socket(s, keyfile=None) results in a call to ussl.wrap_socket(s)).

This would be useful for user-defined libraries that accept a keyfile parameter from their callers and pass this to wrap_socket. (It would provide better compatibility across MicroPython ports and with CPython, without growing MicroPython proper.)

Use case 2: Allow SSL-wrapping of micropython-socket sockets

Due to micropython/micropython#2749, and the fact that socket.socket is a subclass of usocket.socket, micropython-socket sockets cannot be passed to ussl.wrap_socket (attempts to do so cause a crash, for now). This makes the micropython-socket package almost entirely unusable with SSL.

If micropython-socket were modified, though, to wrap instances of usocket.socket, rather than subclassing it, then the proposed micropython-ssl package could provide a wrap_socket function that retrieves the underlying usocket.socket instance from any passed-in socket.sockets before forwarding to ussl.

Perhaps there's a better solution, but this is the only one I can think of besides fixing it in MicroPython proper, as was said here. That might take a while though; even in CPython subclassing native objects has limitations. This solution would affect the result of issubclass(socket.socket, usocket.socket), but I doubt anyone's relying on that (just a guess, though).

Maintainers: What say you? Would this be useful?