Future Maintenance of Mbed TLS
lists.trustedfirmware.orgThat sucks. It's integrated fairly deeply with the Zephyr ecosystem and I'm working on several products that use it, some of them fresly migrated to it...
I've made a PR a while back to add support for authenticated attributes and chain certificates (https://github.com/Mbed-TLS/mbedtls/pull/10232), turns out there are several open PRs for that feature set over the years and they just all sit there. That doesn't inspire contributors to stick around.
As it is used by Zephyr, maybe the Linux Foundation could take ownership and fund the further development of MbedTLS?
I sure hope so. From what I've seen, it's a genuinely well engineered and written library.
I've had to debug both Mbed-TLS and OpenSSL in parallel to figure out a bug in that PR by finding out the point of divergence between the two. The former was a good time, the latter very much not so.
I can only speculate as to why the long-term support of Mbed-TLS 4.1 (which was supposed to last until March 2029) was effectively recanted, but maintaining an internet-facing TLS/X.509/PKCS library in the age of LLM doesn't sound like a good time...
BearSSL is still in beta, but looks very solid already. If all else fails…
no TLS 1.3, and last released in 2018?
True, but its in active development, see https://bearssl.org/gitweb/?p=BearSSL;a=summary.
The thing is very carefully designed.
There are several other embedded-targeted crypto libraries that have been around more or less forever, mbedTLS isn't the only game in town.
What surprised me in the comments are people who use the software for their work who are complaining that they won't be getting updates for free on an Open Source project. People used to pay $$$ to buy licenses to libraries like this... People have a weird understanding of how Open Source works.
> People have a weird understanding of how Open Source works.
Look how's talking.
> who are complaining that they won't be getting updates for free on an Open Source project
Obviously. If you don't have access to the latest source, then it's not Open Source, dummy.
You're misrepresenting the parent comment. It's making the point that work on the project is not free (and could thus be unsustainable despite people desiring updates to bugs or security issues) even if access to the source is free.
However, I do get the feeling from your other comment that you have an axe to grind against this project, so I won't expect high standards.
> You're misrepresenting the parent comment. It's making the point that work on the project is not free
Che? It literally says "people who use the software for their work", and not "people working on MbedTLS". Also, MbedTLS is distributed under a Free and Open Source license, therefore devs rightfully assume to get the latest source under the terms of that said license.
And for the records, the announcement is about MbedTLS being discontinued and only keeping PSA, it's not about a license change or not being free, or whatever.
> I do get the feeling
And you're obviously wrong.
> you have an axe to grind against this project
:FACEPALM: yeah, dude, I've chosen MbedTLS for several projects and have used it for many years because I always wanted to axe it... And I also wanted the latest versions not to compile and not to work with codeberg, may I presume...? (sacrasm)
> I won't expect high standards.
Dude, you misinterpreted the original post and tried to falsely accuse me. Are you seriously trying to talk about standards?
> look who’s talking :’)
This will put a huge amount of projects into trouble, so I'm confident the community will come up with a solution.
But here's one thing I'm wondering: with LLMs being now super-human when it comes to algorithms and computer code, wouldn't it be possible to set up a "project super-harness" for a TLS client library for (not necessarily mbedTLS main branch!!), put up a constant "pool budget" between various individuals and organizations, and let the LLMs care for ongoing maintenance?
Using a crypto library maintained solely by LLMs is not something you want to do, I promise you.
Damn. We just migrated to Mbed TLS for a native app at my work, only this year. I hope some folks with cryptographic chops will step up. It's really a pleasant library use - we were previously using CryptoPP, shudder.
That's nonsense. I've been using MbedTLS for years now in lots of FLOSS projects, and it's biggest mistake was forcing that terrible and buggy PSA API (a mandatory git module in MbedTLS which does not even compile without dirty hacks (*)).
Now they are saying that MbedTLS is going to be discontinued and only the shitty PSA remains? They have lost their minds, time to look for another Open Source alternative, I'm afraid. :-(
(*) - after days of debugging, I've found that an uninitalized variable bug in psa_crypto_mac.c prevents my https client to download files from codeberg. I had to apply a patch to make it work: https://codeberg.org/bzt/ludus/src/branch/main/src/lib/mbedt... That's how "great" PSA is.
Tbh now with the ai you can generate a pretty good tls library in like a day especially if supporting only the latest tls revision is good enough.
Great idea, a TLS library vibecoded by AI in a day.
Please let us know when you generate one, so that we can stay away from it.
Taken at face value your comment is so unbelievably stupid that I have to assume it was joke that failed to land.
Yeah, you're right, internet security infrastructure is exactly the place where you want random vibecode from closed-source black-box code generators. /s
Embedded devices aren't known for security anyway. And the tls library can be written in rust for better memory safety.
If you want a TLS library written in Rust there's already rustls, no need to reinvent the wheel.
Unfortunately it's not entirely clear if rustls can compete in the embedded space where Mbed TLS is most popular?
As a rustls maintainer, we'd love to get feedback about this and/or work with organizations that want to sponsor getting rustls to the point that it could!
> But it's got memory safety. It's what security infrastructures crave!