Like with timing (see my message in the timing thread, https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000061.html), I have a strong preference for the library to be usable out of the box on typical platforms. This means keeping the abstractions that are currently in the net_sockets module, or similar abstractions. This doesn't mean keeping the net_sockets module as such: these abstractions could be in platform.c.

I lean towards having a platform_posix.c and a platform_windows.c (and any other we care to support), chosen at build time based on the target platform. I'm not sure exactly what they should look like. In particular, if you have an embedded platform that's sort of POSIX-like, but doesn't have every POSIX feature and does a few differently, should you be able to customize platform_posix.c through #defines, or should you copy it and modify it to suit your platform?

-- Gilles Peskine Mbed TLS developer

On 20/04/2020 11:52, Manuel Pegourie-Gonnard via mbed-tls wrote:

Hi all,

[ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ]

Currently the SSL/TLS library includes a module called net_sockets.c (formerly net.c), enabled by default in config.h (but disabled by config.py baremetal), that contains some networking functions based on POSIX or Windows sockets, including functions suitable for use as I/O callbacks with our SSL/TLS modules.

Those functions are used only in example/testing programs, but nowhere in the library itself.

In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we're considering removing (parts of) this module from the library, and moving its parts to a variety of other places, such as example programs (or a library/file shared by them, like the current query_config mechanism).

Reasons for removing this module from the library include:

• overall the module is less portable and perhaps of lesser quality than the rest of the library
• it's currently entirely untested on Windows (despite being very platform-specific)
• there are often confusions about whether the module is meant to be a general-purpose networking library, or just provide basic support for our

example and test, as well a simple prototypes

• it's not our core area of expertise, let's do one thing and to it well

Reasons for keeping (parts of) it in the library include:

• having mbedtls_net_recv{,_timeout}() and mbedtls_net_send() available right in the library makes it easier to test and develop prototype
• this module is listed as a component in our high-level design document [2], so perhaps removing it from the library can be seen as a bigger change?

What do you think? Should we remove the entire module from the library, keep it all, or just keep some parts? In that case, which parts and where?

Regards, Manuel.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.