Re: Direct SSL connection and ALPN loose ends
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Dave Cramer <davecramer@postgres.rocks>
Cc: Vladimir Sitnikov <sitnikov.vladimir@gmail.com>,
Heikki Linnakangas <hlinnaka@iki.fi>, Peter Eisentraut <peter@eisentraut.org>, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-06-25T16:05:19Z
Lists: pgsql-hackers
On Tue, Jun 25, 2024 at 7:20 AM Dave Cramer <davecramer@postgres.rocks> wrote:
>
> On Tue, 25 Jun 2024 at 09:37, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>>
>> "SSL". Technically, the proper term is TLS, and even the document refers to "IANA TLS ALPN Protocol IDs" (TLS, not SSL).
>> I would not die on that hill, however, going for tlsnegotiation would look better than sslnegotiation.
>
> +1 again, unusual to use SSL when this really is TLS.
This was sort of litigated last ye-(checks notes) oh no, three years ago:
https://www.postgresql.org/message-id/flat/CE12DD5C-4BB3-4166-BC9A-39779568734C%40yesql.se
I'm your side when it comes to the use of the TLS acronym, personally,
but I think introducing a brand new option that interfaces with
sslmode and sslrootcert and etc. while not being named like them would
be outright unhelpful. And the idea of switching everything to use TLS
in docs seemed to be met with a solid "meh" on the other thread.
--Jacob
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add tests for errors during SSL or GSSAPI handshake
- ef7fa900fb58 18.0 landed
-
Add test for early backend startup errors
- 20e0e7da9bc0 18.0 landed
-
Fix fallback behavior when server sends an ERROR early at startup
- f06a632a77ed 17.0 landed
- c95d2159c1dd 18.0 landed
-
Fix outdated comment after removal of direct SSL fallback
- 5afebbe529ab 17.0 landed
- cc68ca6d420e 18.0 landed