PostgreSQL 11 Beta 2 narrows its channel binding claim
The second PostgreSQL 11 beta exposes a gap between implementing channel binding and letting clients require it, changing how the project describes the feature.
A security mechanism needs a policy for what happens when the mechanism is unavailable. Supporting a stronger authentication exchange does not establish that a connection will reject a weaker exchange. PostgreSQL 11 Beta 2 brings that distinction into its release announcement. The most revealing change concerns the claim the project is prepared to make about channel binding.
The June 28 announcement says that libpq cannot force the use of channel binding. Consequently, channel binding for SCRAM authentication will no longer be described as a major PostgreSQL 11 feature. The announcement presents the beta as a preview whose details can still change. It asks users to exercise application workloads outside production.
I value PostgreSQL's preference for behavior that can be examined in detail. This is a useful example of why that preference should extend to security claims. A feature's name can describe an implemented exchange while leaving out the client's ability to insist on that exchange. An operator needs to know both before assigning the feature a security property.
Capability does not establish enforcement
Bruce Momjian's June 23 message makes the objection explicit. If clients cannot require channel binding, he argues, users may assume protection against a man-in-the-middle attack that the feature does not provide. He recommends removing documentation that could lead to that misunderstanding. The discussion is about the usable guarantee, not simply whether some code for the mechanism exists.
The distinction is general enough to state without assuming a particular exploit. Suppose a client is willing to proceed under either a stronger mode or a weaker mode. Successful connection proves that an accepted mode completed. It does not prove that the stronger mode completed. A policy that requires the stronger mode must include a failure outcome when that mode cannot be established.
This matters when administrators convert a feature list into a deployment requirement. A requirement such as protecting authentication against an active intermediary has a specific threat model. A library capability needs an enforceable connection policy before it can satisfy that requirement. Otherwise, application configuration may contain no way to express the property the administrator believes has been selected.
The beta announcement avoids claiming that a future fix is already available. That restraint is appropriate for a prerelease. The project can describe the limitation it has identified without asking users to rely on a later version or an unresolved design. As of this beta, the relevant fact is the inability to force the mechanism through libpq.
The release claim is part of the interface
Documentation influences which properties an operator assumes during design. Calling channel binding a major security feature can reasonably direct attention toward the protection it is meant to provide. If an essential enforcement control is missing, a prominent description can make the implementation harder to use correctly even when the description of the exchange is technically accurate.
A narrower claim therefore has operational value. It prevents the feature heading from standing in for a complete explanation. Someone designing a connection policy has to examine the supported settings and their failure behavior. The absence of a required mode then remains a visible limitation instead of disappearing behind a capability label.
My judgement is that removing an overstated claim is useful release work. It changes the assumptions under which people adopt software. That work deserves attention alongside implementation fixes because an incorrect assumption can survive a technically successful installation. The application can connect normally while its operator believes the connection has a property the client never required.
The public discussion also gives users evidence of the reasoning. Momjian's message ties the documentation objection to the purpose of channel binding. That makes the disagreement concrete enough to assess. A reader can distinguish a missing enforcement control from an objection to the underlying mechanism itself.
Beta feedback includes behavioral compatibility
Beta 2 also contains fixes involving partitioning, parallel query and upgrade behavior. The announcement lists a correction to fast column addition with non-null defaults during pg_upgrade. These are reminders that a beta needs applications to exercise combinations of features, including maintenance operations. A feature working in a new database does not settle its behavior after an upgrade.
The project requires a major-version-style upgrade procedure even when moving from Beta 1 to Beta 2. That instruction changes how to interpret a beta test environment. It is a database installation with versioned state, not merely a replaceable executable connected to interchangeable files. The method of constructing the test database is part of the result being observed.
For authentication, the useful result is equally specific. A successful login establishes less than a requirement to reject an unacceptable negotiation. For an upgrade, a successful start establishes less than correctness of every migrated object. Both cases require naming the behavior the test is intended to demonstrate before treating success as evidence.
The June beta gives users a clearer account of those boundaries. Its channel-binding statement identifies a control that libpq cannot enforce, and its upgrade instructions identify the procedure needed to reach the new beta. Those details let application authors interpret their observations against the behavior actually available in this release.