PostgreSQL and OpenSSL 4.0.0

First seen: 2026-04-16 13:32:54+00:00 · Messages: 18 · Participants: 4

Latest Update

2026-06-01 · claude-opus-4-6

PostgreSQL and OpenSSL 4.0.0 — May 2026 Summary

Overview

OpenSSL 4.0.0 (GA April 2026) introduced return-value constification on APIs used by PostgreSQL's TLS layer (libpq, contrib/sslinfo), triggering compilation warnings. The thread resolved the technical approach, debated backpatch scope, reached consensus, and produced a rebased patchset ready for commit.

The Technical Problem

The core issue is not OpenSSL 4.0 in isolation but the interaction between OpenSSL 4.0's return-type constification and LibreSSL's lagging API. Specifically:

The patch must span OpenSSL 1.0.1 through 4.0.0 plus LibreSSL — roughly a decade of diverging API evolution.

Solution: Cast-Away-Constness at Call Boundaries

The patch applies unconstify() casts at OpenSSL call boundaries rather than propagating const through PostgreSQL's code or multiplying #ifdef branches. This is explicitly acknowledged as technical debt scoped to stable branches (14–19), not a long-term architectural choice.

A secondary fix addresses an OpenSSL 4.0 diagnostic string change ("ssl alert certificate revoked" → "tls alert certificate revoked") that broke SSL regression tests.

Backpatch Debate and Resolution

The central policy question — how far to backpatch — was debated and resolved:

Gustafsson conceded after realizing he had miscounted remaining 14.x releases. Consensus was reached unanimously.

Forward-Looking: v20 Will Address Root Cause

Gustafsson explicitly stated plans for PostgreSQL 20 to fix the underlying problem — likely by dropping LibreSSL support, splitting code paths, or raising the minimum OpenSSL version. The unconstify() approach is understood as a pragmatic bridge, not permanent architecture.

Current Status

Rebased patchset covering v14 through master posted and awaiting commit after the May 19–23 minor releases ship. Thread is in "waiting for commit" state.

History (1 prior analysis)
2026-06-01 · claude-opus-4-6

Patch Committed to Master; Backpatch Pending Buildfarm Validation

Two new messages from Gustafsson provide logistics updates and one significant architectural revelation:

1. LibreSSL Code Split for v20 (New Architectural Direction)

Gustafsson discloses a WIP patch for PostgreSQL 20 that separates the TLS backend into distinct files: {fe|be}-secure-openssl.c and {fe|be}-secure-libressl.c. This is the concrete plan behind his earlier hint about "fixing this in v20." The explicit goal is to eliminate the ifdef soup that forces lowest-common-denominator casting across diverging OpenSSL/LibreSSL APIs.

This is architecturally significant: rather than raising minimum versions or dropping LibreSSL, the approach is code-path bifurcation — maintaining both backends but allowing each to use its native API idioms without cross-contamination. This directly addresses the root cause identified in the prior round (OpenSSL 4.0 return-type constification conflicting with LibreSSL's non-const signatures in a shared code path).

He signals this will be shared "shortly" as a separate discussion thread for the v20 development cycle.

2. Committed to Master Before Beta1 Deadline

The constification compatibility patch has been pushed to master (May 29), timed ahead of the PostgreSQL 18 beta1 deadline. Backpatching to stable branches (14–17) is explicitly deferred until buildfarm results confirm no regressions on master. This matches the previously agreed strategy of conservative staged rollout, though the trigger shifted from "after minor releases" to "before beta1" — likely due to the illness-induced schedule compression Gustafsson mentions.