Re: Add "password_protocol" connection parameter to libpq

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Add "password_protocol" connection parameter to libpq
Дата
Msg-id 54269124d50791eacb71f1fead40422185ae8ddc.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Add "password_protocol" connection parameter to libpq  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Add "password_protocol" connection parameter to libpq  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Wed, 2019-08-14 at 11:38 +0900, Michael Paquier wrote:
> What I got in mind was a comma-separated list of authorized protocols
> which can be specified as a connection parameter, which extends to
> all
> the types of AUTH_REQ requests that libpq can understand, plus an
> extra for channel binding.  I also liked the idea mentioned upthread
> of "any" to be an alias to authorize everything, which should be the
> default.  So you basically get at that:
> auth_protocol = {any,password,md5,scram-sha-256,scram-sha-256-
> plus,krb5,gss,sspi}

What about something corresponding to the auth methods "trust" and
"cert", where no authentication request is sent? That's a funny case,
because the server trusts the client; but that doesn't imply that the
client trusts the server.

This is another reason I don't really like the list. It's impossible to
make it cleanly map to the auth methods, and there are a few ways it
could be confusing to the users.

Given that we all pretty much agree on the need for the separate
channel_binding param, the question is whether we want to (a) address
additional use cases with specific parameters that also justify
themselves; or (b) have a generic list that is supposed to solve many
future use cases.

I vote (a). With (b), the generic list is likely to cause more
confusion, ugliness, and clients that break needlessly in the future.

Regards,
    Jeff Davis





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Don't like getObjectDescription results for pg_amop/pg_amproc
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)