On 17.03.25 17:49, Jacob Champion wrote:
>>> If we implement this, it needs to check that the keys were actually
>>> sent during scram_exchange(). Having them set on the PGconn doesn't
>>> mean that we used them for authentication.
>>>
>> We use the client key and server key on calculate_client_proof and
>> verify_server_signature respective during memcpy, it would be too hack
>> to add new fields on pg_conn like scram_client_key_in_use and
>> scram_server_key_in_use, set them to true on these functions and then
>> validate that both are true on PQconnectionUsedScramKeys?
> I think that's probably a question for Peter: whether or not that
> additional API is something we want to support.
So the way I understand this is that the options are:
(1) We add a libpq function like PQconnectionUsedScramKeys() in the
style of PQconnectionUsedPassword() and call that function during the
checks.
(2) We make use_scram_passthrough=true imply require_auth=scram-sha-256.
This is essentially a way to get the info from (1) out of libpq using
existing facilities. But it would preempt certain setups that might
otherwise work. (Which ones? Are they important?)
Why can't we use PQconnectionUsedPassword()? What problems would that
leave? The example test case that Jacob showed earlier involved the
remote server using "trust". We don't want that, of course. But what
we want to make sure is that some kind of authentication happened
between postgres_fdw and the remote server. PQconnectionUsedPassword()
does indicate that.
(Or could we just stick in require_auth=!none to solve this problem once
and for all?)
