On 2020/01/21 4:21, David Fetter wrote:
> On Mon, Jan 20, 2020 at 07:44:25PM +0100, David Fetter wrote:
>> On Mon, Jan 20, 2020 at 01:12:35PM -0500, Tom Lane wrote:
>>> David Fetter <david@fetter.org> writes:
>>>> At least two cloud providers are now stuffing large amounts of
>>>> information into the password field. This change makes it possible to
>>>> accommodate that usage in interactive sessions.
>>>
>>> Like who?
>>
>> AWS and Azure are two examples I know of.
>>
>>> It seems like a completely silly idea. And if 2K is sane, why not
>>> much more?
>>
>> Good question. Does it make sense to rearrange these things so they're
>> allocated at runtime instead of compile time?
>>
>>> (I can't say that s/100/2048/ in one place is a particularly evil
>>> change; what bothers me is the likelihood that there are other
>>> places that won't cope with arbitrarily long passwords. Not all of
>>> them are necessarily under our control, either.)
>>
>> I found one that is, so please find attached the next revision of the
>> patch.
>
> I found another place that assumes 100 bytes and upped it to 2048.
There are other places that 100 bytes password length is assumed.
It's better to check the 0001 patch that posted in the following thread.
https://www.postgresql.org/message-id/09512C4F-8CB9-4021-B455-EF4C4F0D55A0@amazon.com
I have no strong opinion about the maximum length of password,
for now. But IMO it's worth committing that 0001 patch as the first step
for this problem.
Also IMO the more problematic thing is that psql silently truncates
the password specified in the prompt into 99B if its length is
more than 99B. I think that psql should emit a warning in this case
so that users can notice that.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters