curl 8.20.0 shipped on April 29, 2026, the latest update to Daniel Stenberg's transfer library that powers an enormous swath of networked software — everything from embedded devices to cloud infrastructure. The release itself follows curl's regular schedule, but the deprecation plans attached to it deserve close attention from anyone working with the library as a dependency.

The most significant 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. TLS-SRP is a method that lets a client prove its password to a server without actually sending the password over the network during the initial handshake. It sounded promising when RFC 5054 specified it in 2007, but adoption never took off beyond a few enterprise and embedded scenarios. OpenSSL, the underlying cryptography library many systems rely on, has been gradually deprioritizing it. Removing it from curl eliminates code that has become increasingly burdensome to maintain.

For most curl users, the August removal will be irrelevant. TLS-SRP only activates when both client and server explicitly enable it; deployments still using it are typically small and intentional. If you rely on it, August 2026 is the deadline — curl's developer documentation lays out the timeline clearly.

SMB protocol support is also slated for removal, though without a fixed date yet. curl's SMB implementation has always been limited compared to dedicated libraries designed for file sharing across networks. It made sense to include when curl was being adopted for file transfer in corporate environments, but modern workflows that need serious SMB functionality — authentication negotiation, share enumeration, NTLM/Kerberos support — have shifted to purpose-built tools. Removing an incomplete, difficult-to-maintain protocol is responsible code hygiene.

This pattern repeats throughout library maintenance at scale. curl runs in billions of devices and is a transitive dependency for vast portions of the open-source ecosystem. Each protocol handler or feature remaining in the codebase carries an ongoing cost: potential security vulnerabilities, compatibility work with new OpenSSL releases, testing against regressions, and the burden on developers navigating the code. Pruning features with negligible real-world adoption is how a project this mature and widespread stays maintainable.

There is a security dimension worth considering here: removing TLS-SRP closes a potential vulnerability vector before it becomes relevant in a post-quantum cryptography migration. SRP's interaction with modern TLS implementations has grown complicated as libraries drop support for older cipher methods, and the risk of misconfiguration creating a false sense of security is genuine. Eliminating it entirely is cleaner than managing its edge cases indefinitely.

curl 8.20.0 and the deprecation work surrounding it are reminders that internet infrastructure undergoes constant, quiet evolution. Version number changes attract attention, but the steady accumulation of thoughtful removals and security decisions is what keeps a 28-year-old library relevant for another decade.