search

Mbed-TLS / mbedtls

An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.
https://www.trustedfirmware.org/projects/mbed-tls/
Other
5.26k stars 2.57k forks source link

Evolution of net_sockets.h in 4.0 #4082

Open daverodgman opened 3 years ago

daverodgman commented 3 years ago

As a first step, explore this issue and determine the best course of action for Mbed TLS 3.0. Options could include:

Mailing list discussion: https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000052.html

This is part of #4030

mpg commented 3 years ago

I don't think there was a strong agreement on the list. The option most likely to eventually get a consensus would be to turn it into a part of a new platform_unix / platform_windows module to be designed.

I think this would require more design work that we can afford for 3.0, and since we agreed to limit 3.0 to simple changes, I'm inclined to post-pone that one to 4.0 and just keep net_sockets as it is for 3.0.

gilles-peskine-arm commented 3 years ago

Given unlimited time, my preference would be to design a new platform module, which would combine things that are today in platform, entropy_poll, timing, net_sockets, etc. We would maintain at least a Unix/POSIX implementation and a Windows implementation of this module — the set of platforms for which we'd maintain an implementation should be the set of platforms we run CI on. OSes that include Mbed TLS and for which our Unix/POSIX implementation doesn't work would maintain their own implementation of this module. This is way out of scope of 3.0.

net_sockets is pretty much what TLS needs. If we move it out of the library, we'd still have to maintain it for the test and sample programs. All we'd gain is that test code needs less robustness. So we lose very little by doing nothing. Doing nothing has my vote.