Request for package: micropython-ssl

[alex-robbins]

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?

[pfalcon]

Somehow I missed this ticket, sorry. Lack of "micropython-ssl" is indeed an oversight, I added dummy implementation of it in ea60d9d. I'll review your other points as time permits, sorry for the further delays.

[alex-robbins]

No worries about delays; I have other things on my list right now too. Since you've added the ssl package, I might submit a pull request implementing "Use case 1", as I described above, since that seems pretty straightforward and uncontroversial.

In the mean time, I'll keep an eye out for your comments. Thanks.

[pfalcon]

So, the aim of micropython-lib is to implement as complete as possible Python stdlib, so in general, this work is welcome. One thing to keep in mind, also in general, is that at last time, there's growing interest to use more of micropython-lib on baremetal targets, the outcome being that the idea that it'll run only on unix, in "unlimited" resources, no longer should be counted on. Nothing of that directly applies to the proposal above, just general things to keep in mind.

So, "Use case 1" indeed can be implemented seamlessly, and I don't see big problems with proposed plan for "Use case 2", just everything needs to be done step by step.

[pfalcon]

Thanks for looking into that btw!

[alex-robbins]

+1 for supporting bare metal ports. It also helps to highlight inconsistencies between ports of MicroPython proper.

As for doing everything step by step, I'm with you there too.

[alex-robbins]

Pull request incoming for "Use case 1", described above. Have not worked yet on Use case 2.