Originally posted by bug77
View Post
Announcement
Collapse
No announcement yet.
Curl Preps For "Probably The Worst Curl Security Flaw In A Long Time"
Collapse
X
-
- Likes 6
-
Originally posted by AmericanLocomotive View PostOf course, there's no guarantee that any applications that rely on the existing version of a library will continue to work once its updated to a newer version. ...at which point, you need to wait for whoever made your program to update it anyways.
- Likes 1
Comment
-
Originally posted by juxuanu View PostRewrite it in Rust.
If you so desperately need your compiler to help you count so that your program functions somewhat properly maybe, then you don't need Rust. You need to select a different career/hobby.
- Likes 2
Comment
-
Originally posted by osw89 View PostFeel free to start working on a replacement together with the 10 other people who program in Rust.- Curl is not shy about using external libs including rust ones for tls, http, and (formerly) quic. This doesn't mean that curl is abandoning openssl and other mature libs, just that it's "diversifying its portfolio" and recognizes the quality of rust libs for critical features.
- Thinking that rust is still a niche or hobby language at this point is just digging your head in the sand. It's serious business for Google, Microsoft, Amazon, Cloudflare, Mozilla, Ferrous and many others. Github already sees more rust pull requests than C, and probably by the end of this year more than C++.
- Likes 5
Comment
-
Originally posted by AmericanLocomotive View PostOf course, there's no guarantee that any applications that rely on the existing version of a library will continue to work once its updated to a newer version. ...at which point, you need to wait for whoever made your program to update it anyways.
- Likes 2
Comment
-
Originally posted by V1tol View Post
That's simply a wrapper around C library. Any language has that.
What most of the people here don't know is that libcurl started looking into Rust quite a long time ago - https://daniel.haxx.se/blog/2020/10/...rl-with-hyper/
- Likes 3
Comment
-
Originally posted by markg85 View PostI'm curlious what that vulnerability is. See what i did there? ^_^
I'm guessing it's a leak that either directly or indirectly allows code execution. Directly could for example be that data fetched through curl is also executed in some probably easy to trigger "facepalm" situation. Indirectly could be that there's a curl leak that isn't directly a security issue for curl itself but that other applications can abuse.
Just guesswork, could also be something different.
- Likes 3
Comment
-
Originally posted by AmericanLocomotive View PostOf course, there's no guarantee that any applications that rely on the existing version of a library will continue to work once its updated to a newer version. ...at which point, you need to wait for whoever made your program to update it anyways.
Application authors are welcome to retest at any dynamic dependency update, but it's not just such a nightmare as you seem to paint it. Debian for example is unlikely to deploy the latest version of a library when a security fix appears. It's more likely to backport the security fix to the version it already used, and the applications shouldn't notice. Now if a distro stayed at old version x and changes to version x+5 because of a security vulnerability, so that they get not only the security fix, but all the new features in between, then applications breaking is more likely. But usually distros should be conservative like DEbian stable and backport fixes or more bleeding edge and then they wouldn't be using old version x already, so any change in version is smaller.
The distribution model has another tool to deal with the remaining risk: the community. Once the library is updated and the application is not, all users get to see the change, and can collaborate in identifying any issue and solve it together, with or without the application author.
For more monolithic deployment of distribution-independent software you get more fragmented community for your particular flat or docker or whatever and less infrastructure to collaborate in a solution, but I don't mean to say that can't be done. I just see flatpaks, dockers, snaps & co. more individualistic and distributions more coordinated and cooperative. But it doesn't have to be always so.
Comment
-
Originally posted by MorrisS. View PostI don't know how end-users could trust developers
- Likes 1
Comment
Comment