Curl 8.4 Released For Addressing A Big Security Vulnerability

[moltonel]

It's an overstatement because nobody so far is writing any part of libcurl in Rust. At best, they're linking to some external libraries which are implemented in Rust.

Remove external libs, and libcurl is largely an empty shell. Those libs are an integral part of libcurl's offering, and changes in what libs curl chooses are significant.

Base http classes and http/1 support is something that libcurl has so far implemented itself. Integrating hyper means transferring some of that core functionality to a Rust lib. Even if it remains an optional dependency, it's replacing (rewriting) a little bit of libcurl C code with Rust code.

[Delgarde]

"partial/gradual kinda-sort-of very slowly" is an overstatement ? I hope nobody understood what I said as "there's a curl rewrite happening". It's just a selection of optional components for the foreseeable future. We can revise that estimate in ten years

It's an overstatement because nobody so far is writing any part of libcurl in Rust. At best, they're linking to some external libraries which are implemented in Rust.

[moltonel]

That's a bit of an overstatement. Libcurl supports a number of backend variants... and one of those variants is binding to an existing Rust HTTP library. That's somewhat short of rewriting Curl itself in Rust.

"partial/gradual kinda-sort-of very slowly" is an overstatement ? I hope nobody understood what I said as "there's a curl rewrite happening". It's just a selection of optional components for the foreseeable future. We can revise that estimate in ten years

In the meantime, I recompiled my curl to use rustls instead of openssl just for the cracks. This is a non-event so far. libcurl is a bit smaller.

[oleid]

Rust is an obvious solution to several issues. But it does have some handicaps. C's advantage is that it's essentially frozen in time. You'll rarely come across code that your C compiler is too old to compile.

Yet, lots of C code didn't work out of the box with modern compilers.

https://wiki.gentoo.org/wiki/Modern_C_porting

Languages like C++ and Rust are a moving target.

Rust promises that you can compile old code with any modern compiler. As long as your compiler is more modern than the code you won't get any problems (unless there is a regression that didn't get detected, of course. But this can happen with any compiler for any language).

[Serafean]

Quoting the blog:

Including the latest two CVEs reported for curl 8.4.0, the accumulated total says that 41% of the security vulnerabilities ever found in curl would likely not have happened should we have used a memory-safe language.

memory safety helps a lot, but is not a panacea.

[Delgarde]

He does name Rust as the obvious rewrite language. And mentions that a partial/gradual rewrite is already kinda-sort-of very slowly happening.

That's a bit of an overstatement. Libcurl supports a number of backend variants... and one of those variants is binding to an existing Rust HTTP library. That's somewhat short of rewriting Curl itself in Rust.

[stormcrow]

You wish. And let's not even talk about hardware where the only available compiler is an abandoned ten year old fork of gcc.



Emphasis on "relatively". Between UB, differences between arches, and regressions, you need some pretty solid testing to distribute to a new hardware/os/compiler. Ever wonder why Linux distributions take months to upgrade gcc ?



Rust/C/C++ are all equally careful about not breaking backward compatibility, So you can upgrade your compiler to suit programs using new language features, without worrying about old programs no longer compiling.

I'd just like to point out that just because a very old C program compiles doesn't mean it'll execute as expected even if you're using the same build chain (GCC, binutils, etc) but distant future version: eg program written for GCC 3 on a Pentium 4 CPU but you have GCC 12 on a Ryzen 5xxx. Sometimes C programs depend on implementation quirks or features in older compiler/linker versions and hardware that don't completely translate to modern expectations. They compile fine, but will crash or give unexpected results when executed because the implementation details evolved over time. That makes some degree of alteration necessary. (Agreeing and elaborating with your statement.) And to be fair, most if not all programming languages are going to have this + more problems with programs that old.

[stormcrow]

C's advantage is that it's essentially frozen in time. You'll rarely come across code that your C compiler is too old to compile. Then different versions of your C compiler will behave relatively similarly.

This isn't true. Not even remotely. It's literally never been true for the entire history of C. I'm working through re-learning (modern -17 standard) C at this very moment and the book goes to pains to point out that C has never been frozen in time, nor do different C compilers behave the same. They have different features and object output let alone the operating system and hardware architectures they're built on top impose their own features, requirements, and limitations.

The C standard itself leaves a great deal up to implementation details. Historically, DEC C wasn't strictly compatible with Sun's C nor IBM C, while MS C will differ from LLVM & GCC. GCC and LLVM definitely implement different parts of the C standard as their code bases grow. Generally speaking, complex or idiomatic C written for GCC won't compile under Visual Studio without changes, and vice versa... and neither one are entirely compatible with Intel's C compiler either. Sure if you stick within the same compiler lineage you'll (possibly - and I mean possibly because things change - errata, deprecation, subtly altered behavior) be ok, but that same C code may not be portable to any other platform or build suite on the same platform nor different generations of the same hardware. Even when C compilers are feature complete with the same version of the standard C89, C11, etc. that doesn't mean they're strictly compatible in all ways with each other - implementation details and extensions will always be the fly in the ointment (and good luck writing performant complex code without -isms).

[moltonel]

C's advantage is that it's essentially frozen in time. You'll rarely come across code that your C compiler is too old to compile.

You wish. And let's not even talk about hardware where the only available compiler is an abandoned ten year old fork of gcc.

Then different versions of your C compiler will behave relatively similarly.

Emphasis on "relatively". Between UB, differences between arches, and regressions, you need some pretty solid testing to distribute to a new hardware/os/compiler. Ever wonder why Linux distributions take months to upgrade gcc ?

Languages like C++ and Rust are a moving target. It would be difficult for an LTS solution to find a compromise between keeping up with Rust releases to allow even backported Curl patches to compile while making sure all their stable (which might be old) software still compiles.

Rust/C/C++ are all equally careful about not breaking backward compatibility, So you can upgrade your compiler to suit programs using new language features, without worrying about old programs no longer compiling.

[stormcrow]

Big shocker that it wouldn't have happened by using a memory safe language. Looking at all of the clowns who continually hate on rust because they're too old or too bad at their job to learn new programming languages.

I wonder if they are the type to complain about a new hard hat comes out that reduces risk of injury due to falling objects by 10% with literally no consequences. "If you just don't get hit then you don't have to worry!!!!!!!!!!!!!"

If people read the Curl team's announcement, it probably wouldn't have happened if whoever brought in the socks code had actually audited it before they did so. Instead, they did like a lot of programmers do: naively copy and pasted example code without bothering to check if it's bug free.

Yes, this wouldn't happen with Rust, Ada/SPARK, or any other memory safe language. And this is a reason why a transition to safer tooling is necessary for the industry. But it also wouldn't have happened if the programmer had done his job in the first place and actually reviewed the code. This is clearly pointed out in the CVS announcement. If this had been a programming logic error rust wouldn't have saved them.