Summary of "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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

If you think the summary is inaccurate, you can reprocess it with the latest model.