Three decades of curl - Daniel Stenberg - NDC Security 2026

Three decades of curl (Daniel Stenberg, NDC Security 2026)

Speaker: Daniel Stenberg (curl founder/maintainer). Also references Rafael Sagula (author of the original HTTP get).

A summary of the talk covering curl’s purpose, history, governance, security practices, development challenges, operational lessons, and outlook.

What curl is

• curl is both a command-line tool (curl) and a C library (libcurl) for URL-based internet transfers.
• Originated from a 1996 tool called HTTP get and evolved into a general-purpose “Swiss Army knife” for network transfers, most famously for HTTP/HTTPS.
• libcurl was introduced in 2000. The codebase is written in C (C89) to maximize portability.

Historical evolution and features

• Lineage: HTTP get (Rafael Sagula) → URL get (1997) → curl (1998).
• Early and ongoing feature additions included FTP, upload support, HTTPS (1998), Telnet, DICT, email protocols, SFTP/SCP, and more.
• Protocol support: 29 protocols as of 2026 (most recent addition: MQTT-S).
• Design scope: focuses on established URL-like protocols that perform uploads/downloads and can ignore content; emphasis on standard, URL-driven transfers.
• Cross-platform reach: runs on hundreds of operating systems and on virtually any CPU ≥32-bit. Widely embedded in phones, servers, appliances, cars, printers, game consoles, and IoT devices.
• Scale: extremely widespread — Daniel estimates on the order of tens of billions (~30 billion) of installations (not precisely measurable).

Project metrics & governance

• Code size: approximately 172k lines of C (after cleanup).
• Contributors:
  • Thousands involved overall (3,600+ named contributors including issue reporters).
  • Around 60–80 active contributors per release.
  • Small core team of ~10–20 people, with roughly 15 people holding push rights.
• Release cadence: regular releases (~every 8 weeks), with 200+ releases to date.
• Licensing: permissive, MIT-like license; the project has been fully open source from the start.

Reliability, stability, and compatibility

• Strong emphasis on backwards compatibility (API/ABI stability). Code from 2006 still builds and runs.
• Project philosophy favors conservative, predictable changes and minimizing breaking behavior to make upgrades low-friction for users.

Security posture and engineering practices

Secure-by-process measures

• Strict coding style guide with enforced linting to keep code readable and consistent.
• Avoidance or wrapping of error-prone libc functions to reduce common C mistakes.
• Active limits on per-function complexity to make code easier to audit.
• No binary blobs and minimal encoded data (lesson learned from incidents such as XZ); avoid embedded secrets (even base64).
• Extensive documentation covering external APIs and internal rationale to aid reviewability.

Testing & analysis

• Large automated test suite and many CI jobs (200+), covering multiple platforms and build/feature combinations.
• Fuzzing on Google OSS-Fuzz for about a decade.
• Dynamic tooling: Valgrind, ASan/UBSan and other sanitizers.
• Static analysis and commercial/AI-powered code scanners used extensively.
• Reproducible builds and signed commits/releases; 2FA required for committers.
• External security audits performed multiple times with few critical findings.

Security realities

• Security bugs still occur. On average a reported security bug had been present in the code for roughly 8 years — highlighting detection challenges and long-lived issues.
• The comprehensive test suite and CI make it difficult to introduce malicious backdoors because pull requests must pass tests across many configurations.

Development process & challenges

• Much work is volunteer-driven. Daniel is the primary full-time maintainer; others contribute either as volunteers or in employer-supported time.
• Onboarding and attracting new contributors is critical to prevent “graying” of the project; first-time authors are an important metric.
• Maintaining a massive, embeddable, cross-platform C codebase requires trade-offs (e.g., retaining C89 for portability).
• Funding is difficult despite ubiquity — heavy usage across devices does not automatically translate into financial support.
• People management and coordinating across the ecosystem are often more challenging than the code itself.

Operational guidance (implicit lessons / best practices)

• Keep code simple, well-styled, and well-documented to ease review and reduce security risk.
• Employ extensive automated testing, fuzzing, sanitizers, and static analysis (including modern AI tools).
• Avoid opaque binary blobs; make code and release artifacts reproducible and auditable.
• Preserve API/ABI stability to retain users and reduce upgrade friction.
• Maintain transparency through public conversations, published security reports, and open processes to build trust.

Future outlook

• As more devices become networked (IoT, appliances, cars), curl deployments are likely to grow.
• Protocols and cryptography will continue to evolve; curl must follow browser/web standards and protocol changes.
• The project’s open-source model supports portability and longevity across platforms and generations.
• No radical replacement is predicted; curl is expected to remain relevant for the foreseeable future.

Resources

• Comprehensive curl documentation and RFC references (Daniel mentions ~1.6 million words of RFC-related documentation).
• Daniel Stenberg has written a book on curl for deeper information.
• Supporting infrastructure/tools referenced: Google OSS-Fuzz, external security auditors, GitHub (project hosting), and various companies/organizations that embed curl.

Main speaker / sources

• Daniel Stenberg — founder and long-time maintainer of curl (primary speaker).
• Rafael Sagula — author of the original HTTP get (early source referenced).
• Additional referenced entities: Google OSS-Fuzz, external security auditors, GitHub, and many companies/organizations embedding curl.