Re: Password identifiers, protocol aging and SCRAM protocol

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Password identifiers, protocol aging and SCRAM protocol
Дата
Msg-id CAB7nPqTxyM+3YbQuevYVZ9MzCBYFAyzSqH2Pk5BaRBy-4GdjfQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Password identifiers, protocol aging and SCRAM protocol  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Password identifiers, protocol aging and SCRAM protocol  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Wed, Sep 28, 2016 at 7:03 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 09/28/2016 12:53 PM, Heikki Linnakangas wrote:
>>
>> On 09/26/2016 09:02 AM, Michael Paquier wrote:
>>>>
>>>> * [PATCH 2/8] Move encoding routines to src/common/
>>>>>
>>>>>
>>>>> I wonder if it is confusing to have two of encode.h/encode.c.  Perhaps
>>>>> they should be renamed to make them distinct?
>>>
>>> Yes it may be a good idea to rename that, like encode_utils.[c|h] for
>>> the new files.
>>
>>
>> Looking at these encoding functions, the SCRAM protocol actually uses
>> base64 for everything.

OK, I thought that moving everything made more sense for consistency
but let's keep src/common/ as small as possible.

> Oh, one more thing. The SCRAM spec says:
>
>> The use of base64 in SCRAM is restricted to the canonical form with
>> no whitespace.
>
> Our b64_encode routine does use whitespace, so we can't use it as is for
> SCRAM. As the patch stands, we might never output anything long enough to
> create linefeeds, but let's be tidy. The base64 implementation is about 100
> lines of code, so perhaps we should just leave src/backend/utils/encode.c
> alone, and make a new copy of the base64 routines in src/common.

OK, I'll refresh that tomorrow with the rest. Thanks for the commit to
extend password_encryption.
-- 
Michael



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

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: Re: pg_dump / copy bugs with "big lines" ?
Следующее
От: Robert Haas
Дата:
Сообщение: psql casts aspersions on server reliability