Remove line length restriction in passwordFromFile()
Per the discussion at [1]/messages/by-id/CAOhmDze1nqG2vfegpSsTFCgaiFRsqgjO6yLsbmhroz2zGmJHog@mail.gmail.com, 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. 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.
Since we now have an actual user complaint, I'm inclined to back-patch
this all the way.
As noted in the other thread, there may be some other changes needed
to support long passwords, but this is clearly required.
regards, tom lane
[1]: /messages/by-id/CAOhmDze1nqG2vfegpSsTFCgaiFRsqgjO6yLsbmhroz2zGmJHog@mail.gmail.com
Attachments:
remove-fixed-buffer-in-passwordFromFile.patchtext/x-diff; charset=us-ascii; name=remove-fixed-buffer-in-passwordFromFile.patchDownload+79-69
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.Since we now have an actual user complaint, I'm inclined to back-patch
this all the way.As noted in the other thread, there may be some other changes needed
to support long passwords, but this is clearly required.
Yes, some client tools have 100 bytes length restriction for the password.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
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
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
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.
Good point, I was being unduly conservative. Thanks for reviewing
the patch!
regards, tom lane
On 2020/09/02 0:14, Tom Lane wrote:
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
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.Good point, I was being unduly conservative. Thanks for reviewing
the patch!
Thanks for committing the patch!
The patch was back-patched to v13, but v13 release note still has the following item.
Tighten libpq's overlength-line handling and comment detection for .pgpass files (Fujii Masao)
This should be changed to the following or something?
Teach libpq to handle arbitrary-length lines in .pgpass files (Tom Lane)
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
The patch was back-patched to v13, but v13 release note still has the following item.
Tighten libpq's overlength-line handling and comment detection for .pgpass files (Fujii Masao)
This should be changed to the following or something?
Teach libpq to handle arbitrary-length lines in .pgpass files (Tom Lane)
Hm. Actually, since that went further back than v13, I don't think
it should appear in the v13 notes at all; it will be material for
the next quarterly update release notes.
We could adjust the release-note entry for your patch to say
"Improve comment detection for .pgpass files", or we could decide
it's not worth documenting that part and just drop the entry.
regards, tom lane
On 2020/09/10 1:48, Tom Lane wrote:
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
The patch was back-patched to v13, but v13 release note still has the following item.
Tighten libpq's overlength-line handling and comment detection for .pgpass files (Fujii Masao)
This should be changed to the following or something?
Teach libpq to handle arbitrary-length lines in .pgpass files (Tom Lane)
Hm. Actually, since that went further back than v13, I don't think
it should appear in the v13 notes at all; it will be material for
the next quarterly update release notes.We could adjust the release-note entry for your patch to say
"Improve comment detection for .pgpass files", or we could decide
it's not worth documenting that part and just drop the entry.
"Improve comment detection for .pgpass files" is also the material for
minor version release because that change was also back-patched?
If so, I agree to drop the entry.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
On 2020/09/10 1:48, Tom Lane wrote:
We could adjust the release-note entry for your patch to say
"Improve comment detection for .pgpass files", or we could decide
it's not worth documenting that part and just drop the entry.
"Improve comment detection for .pgpass files" is also the material for
minor version release because that change was also back-patched?
If so, I agree to drop the entry.
Hm, in a quick search I only see 2eb3bc588 which was not back-patched
... which commits are you thinking of?
regards, tom lane
On 2020/09/10 2:16, Tom Lane wrote:
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
On 2020/09/10 1:48, Tom Lane wrote:
We could adjust the release-note entry for your patch to say
"Improve comment detection for .pgpass files", or we could decide
it's not worth documenting that part and just drop the entry."Improve comment detection for .pgpass files" is also the material for
minor version release because that change was also back-patched?
If so, I agree to drop the entry.Hm, in a quick search I only see 2eb3bc588 which was not back-patched
... which commits are you thinking of?
I thought your commit b55b4dad99 included the improvement on comment detection and was back-patched....
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Fujii Masao <masao.fujii@oss.nttdata.com> writes:
On 2020/09/10 2:16, Tom Lane wrote:
Hm, in a quick search I only see 2eb3bc588 which was not back-patched
... which commits are you thinking of?
I thought your commit b55b4dad99 included the improvement on comment detection and was back-patched....
Oh, right, I did include the check for '#' in what was back-patched.
I debated whether to do that or not, and was misremembering my decision.
So yeah, it seems there's no need to document 2eb3bc588 in the v13
notes. I'll try to remember to give you part credit for b55b4dad9
when I do the November notes.
regards, tom lane