Horton
Menu

Re: Experiments with Postgres and SSL

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Greg Stark <stark@mit.edu>, Andrey Borodin <amborodin86@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Jacob Champion <jchampion@timescale.com>, Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
Date: 2023-07-04T23:33:07Z
Lists: pgsql-hackers 
On Tue, Jul 04, 2023 at 05:15:49PM +0300, Heikki Linnakangas wrote:
> I don't see the point of the libpq 'sslalpn' option either. Let's send ALPN
> always.
> 
> Admittedly having the options make testing different of combinations of old
> and new clients and servers a little easier. But I don't think we should add
> options for the sake of backwards compatibility tests.

Hmm.  I would actually argue in favor of having these with tests in
core to stress the previous SSL hanshake protocol, as not having these
parameters would mean that we rely only on major version upgrades in
the buildfarm to test the backward-compatible code path, making issues
much harder to catch.  And we still need to maintain the
backward-compatible path for 10 years based on what pg_dump and
pg_upgrade need to support.
--
Michael

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Enhance libpq encryption negotiation tests with new GUC

  2. With gssencmode='require', check credential cache before connecting

  3. Add tests for libpq gssencmode and sslmode options

  4. Move Kerberos module

  5. Give nicer error message when connecting to a v10 server requiring SCRAM.