curl 8.20.0 Ships, TLS SRP Deprecation Clock Ticking
curl 8.20.0 Ships, TLS SRP Deprecation Clock Ticking
curl 8.20.0 landed on April 29, 2026, the latest release of Daniel Stenberg's ubiquitous transfer library that underpins an almost uncountable share of networked software — from embedded firmware to hyperscaler toolchains. The release itself is routine by curl's cadence, but the surrounding deprecation schedule is worth tracking closely for anyone maintaining software with a dependency on the library.
The more consequential signal is the planned removal of TLS SRP (Secure Remote Password) support, confirmed in a February 2026 message to the curl-lib mailing list and scheduled for August 2026. SRP is a password-authenticated key exchange mechanism that was once attractive because it avoids transmitting password-derived secrets to the server during the TLS handshake. In practice, it never achieved meaningful traction in the broader web ecosystem — RFC 5054, which specified TLS-SRP, dates to 2007 but saw little adoption outside niche enterprise and embedded use cases. OpenSSL itself has been signaling reduced enthusiasm for the mechanism for years. Removing it from curl trims a maintenance surface that has grown increasingly difficult to justify.
For the overwhelming majority of curl users, the August cut is a non-event. TLS-SRP requires both client and server to be configured for it explicitly; any deployment still relying on it is narrow and deliberate. If that describes your stack, August is not far away — the deprecation notice on curl's developer documentation makes the timeline unambiguous.
SMB protocol support is also on the deprecation list, though without a firm removal date attached as of now. curl's SMB implementation has always been limited relative to dedicated libraries like libsmbclient. Its presence in the codebase made sense when curl was being pushed into file-transfer scenarios across heterogeneous enterprise networks, but the use cases that need real SMB semantics — authentication negotiation, share enumeration, NTLM/Kerberos — have long since moved to purpose-built tooling. Removing a partial, hard-to-maintain protocol implementation is straightforward hygiene.
The pattern here is familiar from library maintenance at scale. curl ships in billions of devices and is a transitive dependency for an enormous portion of the open-source ecosystem. Every protocol handler or feature that remains in the codebase carries an ongoing cost: CVE surface, OpenSSL/TLS backend compatibility work, regression testing, and the cognitive overhead for contributors navigating the code. Pruning features that see negligible real-world use is how a project of this age and reach stays coherent.
Worth flagging for security-conscious teams: the removal of TLS-SRP, while small in blast radius, does close a class of potential vulnerabilities before they can be exploited in a post-quantum migration context. SRP's interaction with modern TLS stacks has become more complex as backends deprecate legacy cipher support, and the risk of a subtle misconfiguration producing a false sense of security is real. Cutting it entirely is cleaner than patching around its edges indefinitely.
curl 8.20.0 and its deprecation trajectory are a reminder that the infrastructure layer of the internet is in constant, quiet revision. The headline version bumps matter less than the steady accumulation of removals and hardening decisions that keep a 28-year-old codebase viable for the next decade.
