C to Rust Refactor in 5 Days: Blitzy Autonomously Rewrote curl
Mar 17, 2026 • Michael Montanaro • 6 min read
640 Engineering Hours. 215,000 LoC. 7,312 Tests. Here's How.
In our first Blitzy Open Source Initiative post, we refactored dnsmasq from C to Rust: 86,000 lines with zero compilation errors.
This time, we went after curl, the most widely deployed data transfer tool in computing history.
curl ships in every Linux distribution, every macOS install, every Windows 10+ machine. curl is baked into cars, televisions, game consoles, and roughly ten billion software installations worldwide.
Refactoring curl in Rust is the kind of project that senior systems engineering teams estimate at 12 to 18 months. Everyone agrees it should be done. Nobody wants to do it.
Why curl?
The White House Office of the National Cyber Director called on the software industry to adopt memory-safe programming languages. The Cybersecurity and Infrastructure Security Agency (CISA) went further, calling development of new critical infrastructure software in C or C++ "dangerous and significantly elevating risk to national security."
curl falls directly under that guidance. Its C codebase carries every memory safety risk that Rust's ownership system eliminates:
- Buffer overflows in protocol parsing
- Use-after-free vulnerabilities in connection handling
- Data races in multi-handle operations
These are the exact vulnerability classes responsible for 70% of CVEs in systems software.
Deep Codebase Understanding: Tech Spec
Before writing any Rust, Blitzy ingested and analyzed the entire curl 8.19.0-DEV C codebase and created a detailed technical specification:
- 179 core library source files, 144,333 lines of code covering the transfer engine, connection cache, protocol handlers, and utility modules
- 43 CLI source files, 19,344 lines handling argument parsing, configuration, callbacks, and output formatting
- 7 TLS backends (OpenSSL, Schannel, GnuTLS, mbedTLS, wolfSSL, rustls, Apple Security Transport), all replaced by a single rustls implementation
- 3 QUIC/HTTP3 backends (ngtcp2, quiche, OpenSSL QUIC), replaced by quinn + h3
- 2 SSH backends (libssh, libssh2), replaced by russh
- 106 public API symbols (CURL_EXTERN) that downstream C programs link against, every one requiring exact signature parity
The analysis also surfaced gaps that would trip up a less thorough approach: roughly 350 configuration directives with implicit behavioral contracts, C #ifdef conditional compilation that needed to map to Cargo feature flags, and a hand-rolled poll()-based event loop with manual state machines across every protocol handler.
What Blitzy Built
See our pull request and our project guide that recaps the work. Here are the numbers:
- 640 engineering hours (80 work days) of autonomous development in 5 days by parallelizing work across specialized agents
- 215,153 lines of production Rust code across 155 source files, organized in a 3-crate Cargo workspace
- 7,312 tests (6,023 library, 833 CLI, 343 FFI, 113 doc tests) with a 100% pass rate. Zero compilation errors. Zero clippy warnings under strict mode.
- Miri validation passed with zero memory safety violations across 1,500+ non-FFI tests
- AddressSanitizer validation passed with zero violations across 7,012 tests including the FFI boundary
- 80.05% line coverage on protocol and transfer modules
- An 8.6 MB release binary and a 7.1 MB shared library exporting 100 curl_ function symbols*
- Zero unsafe blocks outside the FFI crate
- Clear project guide for the remaining work for humans to complete and deploy
The architectural decisions matter as much as the volume. Consider TLS. The C version of curl supports seven different TLS backends (OpenSSL, Schannel, GnuTLS, mbedTLS, wolfSSL, rustls, and Apple Security Transport), each with its own initialization, session management, and certificate validation code. That is seven surfaces for security bugs. The Rust version replaces all of them with a single rustls implementation: pure Rust, no C TLS library linkage at any build configuration.
C (one of seven TLS backends):
/* OpenSSL backend, manual session management */
SSL_CTX *ctx = SSL_CTX_new(TLS_client_method());
SSL *ssl = SSL_new(ctx);
SSL_set_fd(ssl, sockfd);
SSL_connect(ssl); // handshake, manual error checking
// ... who frees what? when? what if SSL_connect fails?
SSL_free(ssl);
SSL_CTX_free(ctx);
Rust (single backend, compiler-enforced safety):
// rustls: one backend, ownership-managed lifecycle
let config = rustls::ClientConfig::builder()
.with_root_certificates(root_store)
.with_no_client_auth();
let conn = rustls::ClientConnection::new(config, server_name)?;
// Connection cleaned up automatically when it goes out of scope
// TLS errors are Result<T, E>, the compiler won't let you ignore them
Seven backends with manual memory management become one backend with compiler-enforced safety. Error handling moved from C's silently ignorable return codes to Rust's Result<T, E> type, where the compiler refuses to let you skip an error check.
Performance Improvements
Startup and local transfers are 2-4x faster than system curl. Static linking eliminates the ~30 shared library loads the C version requires at launch.
CPU-bound internals hold up too:
| Benchmark | Throughput |
|---|---|
| Gzip decompression | 4 GiB/s |
| SHA-256 hashing | 2 GiB/s (hardware SHA extensions) |
| Base64 encoding | 2.24 GiB/s |
Remaining Work
HTTPS to the open internet is currently ~1.5x slower due to missing TLS session resumption, and 11 CLI flags (like -L, -d, -H, --compressed) are parsed but not yet wired to the transfer layer. These are scoped, well-understood gaps in plumbing, not logic. The foundation is solid.
What This Means for curl Users
curl runs on billions of devices, and every one of them inherits the memory safety risks baked into its C codebase. Buffer overflows in DNS parsing, use-after-free bugs in connection reuse, data races under concurrent transfers: these are the vulnerability classes that attackers actively exploit in production infrastructure.
A Rust refactor eliminates them at compile time. For users, that means fewer emergency patches, fewer CVEs to triage, and a fundamentally smaller attack surface on every router, server, and embedded device running curl. The 2-4x startup improvement and static linking also simplify deployment in containerized and embedded environments where dependency management is already a pain point. This is not an incremental improvement. It is a category change in how safe and deployable curl can be.
What's Next
curl was our second open source project, and significantly more complex than the first. With the launch of Blitzy Platform 4.0, we plan to push the boundaries of autonomous software development with each post.
To stay current on Blitzy's Open Source Initiative, follow us on LinkedIn.
