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.
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.
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.
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?
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.
Yeah, you're right, internet security infrastructure is exactly the place where you want random vibecode from closed-source black-box code generators. /s
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.
> look who’s talking :’)
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.
BearSSL is still in beta, but looks very solid already. If all else fails…
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.
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?
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.
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.