Horton
Menu

Re: Experiments with Postgres and SSL

Greg Stark <stark@mit.edu>

View thread
From: Greg Stark <stark@mit.edu>
To: Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
Cc: Andrey Borodin <amborodin86@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-03-31T07:14:03Z
Lists: pgsql-hackers

Attachments

On Mon, 20 Mar 2023 at 16:31, Greg Stark <stark@mit.edu> wrote:
>
> Here's a first cut at ALPN support.
>
> Currently it's using a hard coded "Postgres/3.0" protocol

Apparently that is explicitly disrecommended by the IETF folk. They
want something like "TBD" so people don't start using a string until
it's been added to the registry. So I've changed this for now (to
"TBD-pgsql")

Ok, I think this has pretty much everything I was hoping to do.

The one thing I'm not sure of is it seems some codepaths in postmaster
have ereport(COMMERROR) followed by returning an error whereas other
codepaths just have ereport(FATAL). And I don't actually see much
logic in which do which. (I get the principle behind COMMERR it just
seems like it doesn't really match the code).

I realized I had exactly the infrastructure needed to allow pipelining
the SSL ClientHello like Neon wanted to do so I added that too. It's
kind of redundant with direct SSL connections but seems like there may
be reasons to use that instead.



-- 
greg

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.