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
