Rendered at 04:59:22 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
boricj 22 hours 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 9 hours ago [-]
As it is used by Zephyr, maybe the Linux Foundation could take ownership and fund the further development of MbedTLS?
boricj 8 hours 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...
MrBuddyCasino 20 hours 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 18 hours 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 18 hours 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 11 hours 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 18 hours ago [-]
> look who’s talking
:’)
dsign 21 hours 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 15 hours ago [-]
Using a crypto library maintained solely by LLMs is not something you want to do, I promise you.
yksalun 22 hours ago [-]
[flagged]
widdershins 19 hours 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 19 hours 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 21 hours 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 20 hours 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 17 hours ago [-]
Taken at face value your comment is so unbelievably stupid that I have to assume it was joke that failed to land.
otabdeveloper4 21 hours 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 21 hours ago [-]
Embedded devices aren't known for security anyway. And the tls library can be written in rust for better memory safety.
jabl 20 hours ago [-]
If you want a TLS library written in Rust there's already rustls, no need to reinvent the wheel.
dochtman 16 hours 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 11 hours 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!