On 2020/09/01 10:00, Fujii Masao wrote:
>
>
> On 2020/09/01 6:24, Tom Lane wrote:
>> Per the discussion at [1], we're now aware of actual use-cases for
>> password strings approaching a kilobyte in length. I think this puts
>> the final nail in the coffin of the idea that passwordFromFile() can
>> use a fixed-length line buffer. Therefore, commit 2eb3bc588 (which
>> added a warning for overlength lines) seems rather misguided in
>> hindsight. What we should do instead is fix that code so it has no
>> hard upper bound on the line length.
>
> AFAIR, there were proposals to increase the maximum length of password so far,
> but we could not do that because we failed to get the consensus about
> that change. But if we get the clear use-case requiring longer password and
> reach the consensus, that's good news. I agree with the change.
>
>> Even if you want to say that
>> we'll set a particular limit on how long the password field can be,
>> there's no good upper bound for the length of the hostname field;
>> so ISTM that just getting out of the business of a fixed-size buffer
>> is the sanest way.
>>
>> Hence, the attached proposed patch does that, and for good measure
>> adds some testing of this formerly untested code.
The patch looks good to me, except the following minor thing.
+ if (fgets(buf.data + buf.len, buf.maxlen - buf.len - 1, fp) == NULL)
IIUC fgets() reads the data with the specified size - 1, so ISTM that -1 of
"buf.maxlen - buf.len - 1" is not necessary.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION