MIME-Version: 1.0
References: <27b29a35-9b96-46a9-bc1a-914140869dac@gmail.com> <CAOYmi+=tX4a_eXU5bhj+z7w0ZkZ-EAQ9YLYSnoGxjmdFw8AHxA@mail.gmail.com>
In-Reply-To: <CAOYmi+=tX4a_eXU5bhj+z7w0ZkZ-EAQ9YLYSnoGxjmdFw8AHxA@mail.gmail.com>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Thu, 5 Dec 2024 00:05:00 +0100
Message-ID: <CAGECzQQeq5ze1XBwhb+hbqoOicv5W95GanHA6=x1YG_mnbZyww@mail.gmail.com>
Subject: Re: SCRAM pass-through authentication for postgres_fdw
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Matheus Alcantara <matheusssilv97@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAGECzQQeq5ze1XBwhb%2BhbqoOicv5W95GanHA6%3Dx1YG_mnbZyww%40mail.gmail.com>
Precedence: bulk

On Wed, 4 Dec 2024 at 23:11, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> It makes me a little uneasy to give users a reason to copy identical
> salts/verifiers around... But for e.g. a loopback connection, it seems
> like there'd be no additional risk. Is that the target use case?

I don't think that necessarily has to be the usecase,
clustering/sharding setups could benefit from this too. PgBouncer
supports the same functionality[1]. I only see advantages over the
alternative, which is copying the plaintext password around. In case
of compromise of the server, only the salt+verifier has to be rotated,
not the actual user password.

Regarding the actual patch: This definitely needs a bunch of
documentation explaining how to use this and when not to use this.