Re: Post-CVE Wishlist

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Post-CVE Wishlist
Date: 2021-11-24 08:26:55
Message-ID: 3e737f68-24cf-2012-5ee8-00c085ae652d@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24/11/2021 07:09, Michael Paquier wrote:
> On Tue, Nov 23, 2021 at 02:18:30PM -0500, Tom Lane wrote:
>> Jacob Champion <pchampion(at)vmware(dot)com> writes:
>>> = Client-Side Auth Selection =
>>> The second request is for the client to stop fully trusting the server
>>> during the authentication phase. If I tell libpq to use a client
>>> certificate, for example, I don't think the server should be allowed to
>>> extract a plaintext password from my environment (at least not without
>>> my explicit opt-in).
>>
>> Yeah. I don't recall whether it's been discussed in public or not,
>> but it certainly seems like libpq should be able to be configured so
>> that (for example) it will never send a cleartext password. It's not
>> clear to me what extent of configurability would be useful, and I
>> don't want to overdesign it --- but that much at least would be a
>> good thing.
>
> I recall this part being discussed in public, but I cannot put my
> finger on the exact thread. I think that this was around when we
> discussed the open items of 10 or 11 for things around channel binding
> and how libpq was sensitive to downgrade attacks, which would mean
> around 2016 or 2017. I also recall reading (writing?) a patch that
> introduced a new connection parameter that takes in input a
> comma-separated list of keywords to allow the user to choose a set of
> auth methods accepted, failing if the server is willing to use a
> method that does not match with what the user has put in his list.
> Perhaps this last part has never reached -hackers though :)
>
> Anyway, the closest thing I can put my finger on now is that:
> https://www.postgresql.org/message-id/c5cb08f4cce46ff661ad287fadaa1b2a@postgrespro.ru

Here's a thread:

https://www.postgresql.org/message-id/227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel%40j-davis.com

The result of that thread was that we added the
channel_binding=require/prefer/disable option.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-11-24 08:44:20 Re: pg_get_publication_tables() output duplicate relid
Previous Message Masahiko Sawada 2021-11-24 08:19:40 Re: Skipping logical replication transactions on subscriber side