curl 8.22.0: what the repository does not tell you about installing it

One project, two artifacts, two manuals

The repository builds two things that share a name and a bug tracker: the curl command line tool, and libcurl, the library the tool itself uses to do its job. The README routes you to two different manuals depending on which one you mean, the man page at curl.se/docs/manpage.html for the command and the libcurl man page for the library, with everything.curl.dev offered as a second path into the same knowledge. The library is described as readily available for your own software, and that is the detail worth slowing down on. curl is not only a program you run, it is also a dependency other programs link against, so the two have separate documentation, separate upgrade decisions, and different obligations on whoever adopts them.

The tree reflects the split. src/ holds the command, lib/ the transport library, include/ the public headers, and curl-config.in plus libcurl.pc.in are the two install descriptors generated during a build, which is where a packager's work becomes visible. A layout that separates the tool from the library this cleanly is also why a machine can carry a curl binary that is not the same build as the libcurl sitting beside it.

Nothing in the README explains how to check which of the two you are looking at, so that verification belongs to you before you depend on either one.

Twenty-seven scheme names, and no claim about what any of them does

The protocol list is the project's real identity, and it is long: DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS, 27 names in all, with each TLS variant listed separately from its plaintext parent instead of appearing as an option on it.

That breadth is both the pitch and the trap. A script that builds a URL without thinking about the scheme can end up on FTP, on TELNET, or on a plain WS socket, none of which carry the guarantees people read into an https:// prefix, and the scheme is chosen by the string someone typed rather than by configuration you control. Every one of those 27 handlers is also a separate place where a parser bug can hide.

What this README does not do is describe any of them. There is no table mapping schemes to features, no note about what happens when a scheme is left out of a build, and no list of options at all. Those answers live in the man page, and their library equivalents in the libcurl man page, which is a reasonable division of labor and a real cost to anyone who wants a one page orientation before installing anything.

No install command in the tree, only a pointer to the INSTALL document

There is no line here that installs curl, and the project does not pretend otherwise. Installation is delegated to a separate INSTALL document at curl.se/docs/install.html, and the only command offered for obtaining the code points at the Git server:

git clone https://github.com/curl/curl

Consequence for you: if you are writing a Dockerfile, a CI job, or a build script, this repository hands you nothing to paste. No package line, no formula, no prebuilt artifact reference, no list of platform packages. You either route through your distribution's package and accept whatever version it carries, or you work through the INSTALL document and the build system on your own.

The same delegation runs through the rest of the page. The website is named as the place for the latest news and downloads, so even the binaries are treated as something fetched from elsewhere rather than something this tree hands you.

The Dockerfile is a pinned release sandbox, not a product image

The repository's Dockerfile does something narrower than its filename suggests. The first comment calls it a self-contained build environment to match the release environment, and its purpose is a reproducible build, not a packaged, runnable curl:

docker build --build-arg SOURCE_DATE_EPOCH=1711526400 --build-arg UID=$(id -u) --build-arg GID=$(id -g) -t curl/curl .

The base is Debian bookworm-slim pinned by digest rather than by a floating tag, the toolchain is a fixed list (build-essential, make, autoconf, automake, libtool, git, perl, zip, zlib1g-dev, gawk), and the image creates a dev user carrying your own UID and GID so files you generate are not owned by root. SOURCE_DATE_EPOCH is a build argument with a fallback of 1, which puts timestamp hygiene inside the build image instead of in a release checklist.

Consequence: once the build finishes you have a shell with curl's build tools, not an installed curl. The image is designed to be run with a checkout mounted into it, and every example that follows assumes exactly that shape.

The example commands still build 8.7.1, and they turn TLS off

The build examples in that same comment block are the part copied most often and trusted least carefully:

docker run --rm -it -u $(id -u):$(id -g) -v $(pwd):/usr/src -w /usr/src curl/curl autoreconf -fi
docker run --rm -it -u $(id -u):$(id -g) -v $(pwd):/usr/src -w /usr/src curl/curl ./configure --without-ssl --without-libpsl
docker run --rm -it -u $(id -u):$(id -g) -v $(pwd):/usr/src -w /usr/src curl/curl make
docker run --rm -it -u $(id -u):$(id -g) -v $(pwd):/usr/src -w /usr/src curl/curl ./scripts/maketgz 8.7.1

Two details deserve a second look. The tarball step names 8.7.1, which sits well behind the current release line, where the recent tags are curl-8_20_0 from 2026-04-29, curl-8_21_0 from 2026-06-24 and curl-8_22_0 from 2026-09-02. And the configure step passes --without-ssl --without-libpsl, which builds a binary with TLS support turned off and no local public suffix list, the opposite of what a deployment would ship.

Consequence: a tarball produced by following the comment exactly is both mislabeled and unusable for https. Substitute your own version string, then read the configure options your target actually needs before you believe the output matches the binary people expect from the name.

Autotools and CMake live in the same tree

Both build paths are checked in. The autotools side is configure.ac, acinclude.m4, Makefile.am and m4/, which is why the sandbox image installs autoconf, automake and libtool and why the first example command is autoreconf -fi. The CMake side is CMake/ and CMakeLists.txt at the root. Two build systems over one source tree means two configurations of the same code, and there is no promise in the README that they expose identical options, so something that builds under one path can be missing from the other.

The rest of the top level shows what a change is expected to satisfy. .clang-tidy.yml and .editorconfig cover style, .mailmap keeps author identity readable in history, .git-blame-ignore-revs records the reformatting commits that would otherwise pollute blame, renovate.json covers dependency updates, .circleci/ and appveyor.yml carry continuous integration, and tests/ is where behavior gets pinned. CHANGES.md, RELEASE-NOTES and GIT-INFO.md remain at the root as the written record of what changed and which commit it came from.

The metadata says NOASSERTION while the source says MIT-like

The repository metadata reports the license as NOASSERTION, which is what a project using its own license text looks like to a field that expects a recognized SPDX identifier. The source files carry SPDX-License-Identifier: curl, COPYING sits at the root, LICENSES/ holds the per-file license texts, and REUSE.toml carries the reuse specification, while the README describes the terms as an MIT-like license.

Consequence for teams: a dependency scanner, an SBOM generator, or a compliance checklist that keys on SPDX identifiers will come back empty on this repository, even though the terms are permissive and the copyright text is easy to locate. If procurement or legal review is part of your process, read COPYING and the LICENSES/ directory rather than trusting the metadata field. What you have here is a reporting gap, not a restrictive license.

Security reports go private, and no clock is promised

Vulnerability handling gets one instruction, and it is firm: report suspected security problems privately and not in public. Everything else is pointed at ordinary channels, mailing lists, GitHub issues, pull requests, and discussions. SECURITY.md sits at the root next to COPYING and RELEASE-NOTES.

What the README does not provide is a timetable. There is no stated response time, no coordinated disclosure window, no bug bounty, and no severity policy, only a link to the reporting page. For a project embedded in operating systems, build systems, and language runtimes, that gap is the one you feel: you can report a problem and still have no basis for planning your own remediation schedule from anything documented on this page.

The funding and support routes are more concrete: GitHub Sponsors, an Open Collective page for backers, a sponsors page, and a support page for people who need private and dedicated help with their own problems or applications built on (lib)curl. Every contributor is listed in the THANKS document.

Editorial conclusion

curl is the right dependency when you need one URL syntax across many transports, or libcurl when you need that transfer layer inside your own program, and the permissive terms plus a sub-second binary make adoption easy. It is the wrong starting point if you wanted a supported product, a documented install command, a stated vulnerability response time, or a build that ships TLS by default, because none of those come from this tree. Before you depend on it, check which libcurl your build is linking, read COPYING rather than the license metadata, confirm your tarball is labeled with the version you actually built, and decide who responds when a protocol handler turns out to be broken.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes