That 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.
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...
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?
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.
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.
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?
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.
20 comments
[ 8.6 ms ] story [ 77.8 ms ] threadI'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.
The thing is very carefully designed.
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...
Please let us know when you generate one, so that we can stay away from it.
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?
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.
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.
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?
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.