Curl Preps For "Probably The Worst Curl Security Flaw In A Long Time"

[mb_q]

I know you were just yanking people's chains, but, sadly, curl isn't part of coreutils which already has a Rust counterpart. The approach for Rust seems to be to simply wrap libcurl: https://docs.rs/curl/latest/curl/

That is literally the Rust wrapper of libcurl, so sure. The "Rust libcurl" is called reqwest, although it is HTTP only (not that many people are browsing Gopher with curl, but still). There are some CLIs for reqwest, for instance, xh (though its interface mimics httpie not curl, which arguably is a good thing).

[Danny3]

Of 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.

That's much less likely as most of the times a program will work also with an updated version of a library, but that's a possibility too.

[quaz0r]

Rewrite it in Rust.

Or god forbid just learn to code. Or learn to care enough to take the time to not just shit out whatever inaccurate garbage falls out your backside and call it good until something goes wrong.

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.

[moltonel]

Feel free to start working on a replacement together with the 10 other people who program in Rust.

Come on... The call to rewrite curl in rust was a joke (or if it wasn't, feel free to treat it as such). However

• 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++.

[Serafean]

Of 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.

But there's a 100% chance your entire system is vulnerable through the one program not using the system library that someone forgot to update. I'll take faint probability of one program breaking instead of a completely unmanageable and bugged/vulnerable system.

[timofonic]

I don't know how end-users could trust developers

Learn programming should be mandatory to use a computer, just like a driver's licenseto drive a car or whatever vehicle.

[Quackdoc]

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/

this is actually cool, I didn't actually know much about curl itself, so this article, not only cool for hyper, but also gives a quick entry into how curl works. thanks

[fitzie]

I'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.

i'll do one better, not only it's it's code execution from data fetched, it's done via some esoteric protocol that can be triggered via http redirect. i remember the log4j bug, that made 99% of log4j deployments exploitable for a feature that 0.1% of the deployments actually used. I'd predict 90% this will be the same type of thing, just dormant codepaths activated and exploited. 10% it's some certificate validation flaw allowing for MITM or something like that.

[phoron]

Of 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.

There is no absolute guarantee, but there's the guarantee of the library developers knowing how the library is supposed to be used and how to fix a vulnerability without damaging expected uses. If the application does weird things with the library (like relying on its vulnerabilities) then yes, the application may break. But that should be unlikely.
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.

[phoron]

I don't know how end-users could trust developers

if they're non programming end users then they're blind, trusting is easy because they don't know what programmers can do to them (willing or not). If they are programming users... they just don't trust (other?) developers and make do as well they can anyway.