Removing Broken Support for OpenSSL without ECDH

Technical Problem

PostgreSQL's SSL/TLS implementation contains dead code paths guarded by the OPENSSL_NO_ECDH preprocessor macro, which was introduced in commit 316472146 (2013) to conditionally compile ECDH (Elliptic Curve Diffie-Hellman) key exchange support. The intent was to gracefully handle OpenSSL builds that lacked ECDH capability.

However, OpenSSL itself removed the OPENSSL_NO_ECDH macro in 2015 (OpenSSL commit 10bf4fc2c), merging it with OPENSSL_NO_ECDSA into a unified OPENSSL_NO_EC macro. Since PostgreSQL never updated its conditional compilation guards to track this upstream change, the #ifdef OPENSSL_NO_ECDH checks have been completely inert for over a decade — the macro is never defined by any supported OpenSSL version, so the guarded code paths (which would disable ECDH) are never activated.

Architectural Significance

This is a code hygiene issue rather than a functional bug, but it matters for several reasons:

1. Dead code obscures intent: Developers reading the SSL code might believe there's active support for non-ECDH configurations, leading to incorrect assumptions about the code's behavior.

2. False sense of portability: The guards suggest PostgreSQL handles diverse OpenSSL configurations, when in reality it has silently required ECDH support since 2015.

3. ECDH is essential for modern TLS: Elliptic curve key exchange is fundamental to TLS 1.3 and widely used in TLS 1.2. Any OpenSSL build without EC support would be effectively unusable for modern cryptography, making the conditional compilation pointless even if it worked correctly.

Proposed Solution

The patch simply removes the OPENSSL_NO_ECDH guards and their associated conditional compilation blocks, making the ECDH code unconditional. This is a safe cleanup because:

• No supported OpenSSL version defines OPENSSL_NO_ECDH anymore
• No user has ever reported breakage from this being non-functional (confirming nobody builds OpenSSL without EC in practice)
• The change is proposed for master only (no backpatch needed since it's purely cosmetic cleanup)

Design Decisions

• No replacement with OPENSSL_NO_EC: Rather than "fixing" the guards by updating them to check OPENSSL_NO_EC, the proposal correctly identifies that supporting OpenSSL-without-EC is an anti-feature. Modern PostgreSQL should simply require EC support from its OpenSSL dependency.
• Master-only application: Appropriate since there's no behavioral change and no bug being fixed — this is purely code simplification.

Historical Context

The timeline reveals a common pattern in long-lived projects with external dependencies: upstream API changes go unnoticed when the affected code path is rarely (or never) exercised. The 10+ year gap between OpenSSL removing the macro and PostgreSQL cleaning up the dead code illustrates how defunct compatibility shims can persist indefinitely without causing obvious harm.