curl-for-win ships static, reproducible curl binaries you can verify

Static curl binaries for machines without a package manager

The problem is familiar to anyone who has scripted Windows: curl is either absent, or it is the ancient system copy that lacks modern protocol support. curl-for-win answers that with prebuilt static binaries, and the scope is wider than the name suggests, since the project publishes packages for Linux, macOS and Windows. The description is exactly that: reproducible, static, curl binaries for Linux, macOS and Windows. What ships is a standalone curl, a standalone trurl, and a libcurl DLL, with static libraries included. That combination matters for two different audiences. A platform engineer can drop the binaries onto a machine with no compiler and no runtime to install, and a developer linking against libcurl gets the same code as the tool rather than a different library version. The downloads are distributed as .zip or .tar.xz packages from the curl.se/windows page, and the project is maintained through sponsorship on GitHub Sponsors, which the README links as the way to support maintenance and fixes.

Four signature schemes for the same package

The distinguishing feature of these builds is that verification is a first class part of the download instructions, and the project supports four key types rather than picking one. With sigstore and cosign, using the published public key:

cosign verify-blob --key cosign.pub.asc --bundle curl-8.16.0-win64-mingw.zip.sigstore curl-8.16.0-win64-mingw.zip

With minisign and its own public key:

minisign -VP RWQcXBEFq5MO2MDhlrz30eklTuapCJXgMYBo3WDnlugoumiHsewGfvfK -m curl-8.16.0-win64-mingw.zip

With OpenSSH, using the id file in the repository:

ssh-keygen -Y verify -n file -f id-curl-for-win-sign.id -I id-curl-for-win-sign -s curl-8.16.0-win64-mingw.zip.sig < curl-8.16.0-win64-mingw.zip

And with PGP, after importing the key whose fingerprint the README prints:

gpg --import sign-pkg-public.asc
gpg --verify curl-8.16.0-win64-mingw.zip.asc curl-8.16.0-win64-mingw.zip

The point of offering four is not redundancy for its own sake. A corporate environment may have exactly one of these key stores provisioned, and a package manager that insists on one scheme will otherwise push you towards fetching binaries without any check at all. The repository holds the corresponding public key files, including cosign.pub.asc, minisign.pub, id-curl-for-win-sign.id and sign-pkg-public.asc.

Minimum platforms are stated down to the kernel version

The runtime requirements are listed precisely, which matters when you are deciding whether a build will run on an old fleet machine. For Windows the requirement is Windows Vista with the Universal CRT, on ARM64 or x64. For macOS it is macOS 10.14 Mojave, on arm64 or x86_64. For Linux it is kernel 2.6.39 or newer, on amd64, arm64 or riscv64, using MUSL builds. The MUSL detail is the one that surprises people: these Linux binaries are linked against musl libc rather than glibc, which is what makes them static and portable across distributions, at the cost of not behaving exactly like a distribution packaged curl. Protocol support includes HTTP/3 and HTTP/2, listed alongside a larger feature matrix in the README. That matrix is worth reading rather than skimming, because it also lists variants named noh3, mini, micro, nano and pico with different capability sets, so the package you want may be a cut down build rather than the full one.

Reproducible builds in public CI, with the hashes in the log

The reproducibility claim is specific rather than decorative: the project builds reproducible binaries, producing the same hash given the same input sources and C compiler. That is a property of the whole pipeline, and the pipeline is visible. Windows is cross built and published via AppVeyor CI, Linux is built via GitHub Actions using a reproducible container image, debian:testing-slim, via rootless podman, and macOS is built via GitHub Actions as well. Transparent builds, using open source code, run in public with auditable logs, and the README states you can look up the package hashes in lines starting with SHA in the build log. That closes the loop for anyone who wants to check a published artifact against the build that produced it. The components are also verified with SHA-256, and via digital signatures if provided. The toolchain is LLVM/Clang with mingw-w64 obtained through Debian, Homebrew or MSYS2, and llvm-mingw for ARM64, with ARM64 host machines used when available for efficiency.

Control Flow Guard, CET and self signed code signing

Hardening is where a static binary build has to work harder than a distribution package, and the project documents what it does. Windows 64-bit builds are Control Flow Guard enabled, Intel builds have CET enabled, and all builds have frame pointers enabled. Those three choices come from the compiler flags used for the Windows build, and they matter because a prebuilt binary is code you did not compile on the target machine. Signing is handled differently, and it is worth being precise about it: the project code-signs with a self signed certificate on Windows, and avoids trusted timestamps for reproducibility. A self signed certificate is not the same as a certificate from a commercial authority, so it does not by itself satisfy an organisation that requires a chain to a trusted root. What it does provide is integrity binding of the binary to the signing key, and the package level signatures described earlier provide the independent check. The patch policy is likewise conservative: no local patches, with changes applied only if already merged upstream, or for showstoppers, submitted upstream with fair confidence of getting merged.

Not official curl builds, and a licence split inside the repository

Two caveats prevent a misreading of what these artifacts are. First, the Linux and macOS builds are not official curl builds. The Windows packages are the primary output, and the other platforms are provided as a convenience, so anyone with a strict policy on vendor support should treat them accordingly. Second, the licence situation is not uniform. The repository is MIT licensed, and it also carries a REUSE.toml file and a LICENSES/ directory alongside LICENSE.md, which is how the project keeps third party component licences traceable inside a build that vendors a lot of them, from the TLS backend to compression and SSH libraries. The requirements file in the repository, which pins pefile at version 2024.8.26 for the Windows packaging work, is a small but telling detail: the build scripts inspect binaries, so packaging itself needs tooling. The repository is a collection of shell driven build scripts, from _build.sh and _pkg.sh to per library files such as libressl.sh, brotli.sh and libssh2.sh, with appveyor.yml at the root and a daily workflow badge in the README.

Editorial conclusion

Adopt curl-for-win when you need a curl on a machine you do not control, a pinned build for a reproducible CI job, or a trurl and libcurl DLL alongside the tool, and when your security policy requires a signature check on every downloaded binary. Do not adopt it as a drop in replacement for an official curl release on Linux or macOS, because the project states those builds are not official curl builds, and expect a Windows specific toolchain rather than a portable distribution format. Verify first that the signature you check against is the one your organisation pinned, since four different key types are published, and that the hash of the specific build matches the SHA line in the build log for that release.

Frequently asked questions

Official sources

1. curl/curl-for-win on GitHub
2. Issues
3. License: MIT
4. Project website
5. README