Re: Password identifiers, protocol aging and SCRAM protocol

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Password identifiers, protocol aging and SCRAM protocol
Дата
Msg-id 21507128-dc47-fe39-e90c-1ac85ef80aa7@iki.fi
обсуждение исходный текст
Ответ на Re: Password identifiers, protocol aging and SCRAM protocol  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Password identifiers, protocol aging and SCRAM protocol  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
On 09/26/2016 09:02 AM, Michael Paquier wrote:
> On Mon, Sep 26, 2016 at 2:15 AM, David Steele <david@pgmasters.net> wrote:
>> * [PATCH 3/8] Switch password_encryption to a enum
>>
>> Does not apply on HEAD (98c2d3332):
>
> Interesting, it works for me on da6c4f6.
>
>> For here on I used 39b691f251 for review and testing.
>> I seems you are keeping on/off for backwards compatibility, shouldn't
>> the default now be "md5"?
>>
>> -#password_encryption = on
>> +#password_encryption = on              # on, off, md5 or plain
>
> That sounds like a good idea, so switched this way.

Committed this patch in the series, to turn password_encryption GUC into 
an enum.

There was one bug in the patch: if a plaintext password was given with 
CREATE/ALTER USER foo PASSWORD 'bar', but password_encryption was 'md5', 
it would incorrectly pass PASSWORD_TYPE_MD5 to the check-password hook. 
That would limit the amount of checking that the hook can do. Fixed 
that. Also edited the docs and comments a little bit, hopefully for the 
better.

Once we get the main SCRAM patch in, we may want to remove the "on" 
alias altogether. We don't promise backwards-compatibility of config 
files or GUC values, and not many people set password_encryption=on 
explicitly anyway, since it's the default. But I kept it now, as there's 
no ambiguity on what "on" means, yet.

- Heikki




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

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: Push down more full joins in postgres_fdw
Следующее
От: Greg Stark
Дата:
Сообщение: Re: LLVM Address Sanitizer (ASAN) and valgrind support