Rendered at 02:19:23 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
boricj 2 days ago [-]
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.
hommelix 1 days ago [-]
As it is used by Zephyr, maybe the Linux Foundation could take ownership and fund the further development of MbedTLS?
boricj 1 days ago [-]
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...
pseudohadamard 13 hours ago [-]
There are several other embedded-targeted crypto libraries that have been around more or less forever, mbedTLS isn't the only game in town.
MrBuddyCasino 2 days ago [-]
BearSSL is still in beta, but looks very solid already. If all else fails…
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.
skrellm 2 days ago [-]
> 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.
xenocratus 2 days ago [-]
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.
skrellm 1 days ago [-]
> 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?
krekr 2 days ago [-]
> look who’s talking
:’)
dsign 2 days ago [-]
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?
AlotOfReading 1 days ago [-]
Using a crypto library maintained solely by LLMs is not something you want to do, I promise you.
yksalun 2 days ago [-]
[flagged]
widdershins 2 days ago [-]
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.
skrellm 2 days ago [-]
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.
mono442 2 days ago [-]
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.
grodriguez100 2 days ago [-]
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.
crest 2 days ago [-]
Taken at face value your comment is so unbelievably stupid that I have to assume it was joke that failed to land.
otabdeveloper4 2 days ago [-]
Yeah, you're right, internet security infrastructure is exactly the place where you want random vibecode from closed-source black-box code generators. /s
mono442 2 days ago [-]
Embedded devices aren't known for security anyway. And the tls library can be written in rust for better memory safety.
jabl 2 days ago [-]
If you want a TLS library written in Rust there's already rustls, no need to reinvent the wheel.
dochtman 2 days ago [-]
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!
otabdeveloper4 1 days ago [-]
> But it's got memory safety. It's what security infrastructures crave!
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'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...
The thing is very carefully designed.
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?
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?
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.
Please let us know when you generate one, so that we can stay away from it.
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!