No, I’m kidding. But curl’s maintainer has very interesting thoughts about the rewriting of curl in a memory-safe language (he discusses only Rust). Spoiler: it won’t be done by the current curl team.
7 Likes
Using another language was brought up again last week after another security flaw. Rather than just pointing to Zig and saying it can be made safer incrementally, I did the port with the help of Copilot. It is an experiment and I’ve already received very good feedback. You can see how it was done here:
I don’t think dumping LLM crap on the lap of Curl maintainers is going to help them, or help Zig reputation. Please refrain to do so.
James Fuller response was surprisingly cordial, but it looks like you didn’t read it and just copy pasted in Claude.
Also note that Zig doesn’t have cImport anymore, so your arguments are misleading.
If you want to showcase Zig, you need to start way smaller, maybe with a build.zig. Zig can already translate C code automatically. So the mechanical translation feature of LLMs has little value here.
The next step would be to identify some part of Curl that would most benefit from an incremental rewrite in Zig.
See Maintain it With Zig | Loris Cro's Blog
btw @kristoff your blogpost have some broken GH link
35 Likes
There are subtle gotchas in language translation that the process didn’t guard against.
The oracle has to be created independently of the translator, and the translator must not be able to modify it, bypass it, or get changes through without passing it. Those roles shouldn’t share context. The translator’s own unit tests should have zero bearing on whether the translation is judged correct. They’re a completely separate kind of testing.
In this case - curl’s own test suite wasn’t wired into CI until after the release, and the runner still uses -n, which disables valgrind. “Tests green” isn’t enough, even when the right tests ran. Define the observable behavior up front, require it to match the C version, and check that with seeded differential fuzzing of the C and Zig implementations side by side. Parity alone also can’t catch bugs C already has, like the one that was called out, so safety claims need sanitizers or valgrind on top.
I’d put the process itself, not the code, through a few adversarial reviews before repeating this - And go slower: start with a handful of functions, each switchable back to C, to develop the process and build the safety case, rather than replacing all 239 files in 13 hours. I’d also have liked to read this as a regular post first rather than as a message to the curl team.
1 Like
I’m honestly appalled by such behavior, Curl in an amazing project, and to think he even gave you the time of day, is beyond me, I’m repulsed by this kind of forced waste of time, it is extremely inconsiderate and selfish on your end. I really don’t understand what went through your mind doing this, and thinking this would have any positive outcome.
It’s cool to try to push zig to other projects, but this is clearly not the way to do it, and reflects poorly on a community that values craftsmanship. You need to do better.
9 Likes
isn’t that an insta-ban?
Yes, curl is an amazing project! No, there is nothing wrong with doing an experiment in my own fork on github. In fact, that is the spirit of open source and should be encouraged. Y’all really should be kinder.
One of the reasons curl explored using rust was to prevent security errors. Of the 239 curl CVEs in the last 6 years, 75 are labeled “C mistakes”. An estimate is that a full rewrite to rust would have prevented all 75 of them. The estimate for the zig port is that it would have taken care of 64 of them, about 85%. It makes a strong case for moving to Zig from C/C++ projects.
In the end, it passed all tests and is installable across Mac, Linux, Windows with a single ghr install cataggar/curl. If the port was attempted again, I would follow @awesome4000 good advice and use this first port as input.
Please keep the conversation technical and cordial.
2 Likes
There is nothing wrong with experimenting, that is true, what is wrong in my opinion is dumping it on someone. Experiments can inform you, help you understand, learn, etc. But I don’t see how dumping 177k lines of code even if handwritten would be helpful. Instead creating a PR where you add a build.zig, and replace one of the problematic CVE part with zig code that makes it impossible to get the error, that would have been helpful, and informed the maintainer probably better. And at the very least you should have tested what you did, it seems like he had issue with compiling and testing it, because you didn’t care enough to do it yourself. And don’t take this the wrong way but you don’t have technical discussion without humans. So if you don’t learn how to speak to people respectfully with considerations, you won’t reach the technical discussion.
6 Likes