Re: Should rolpassword be toastable?

On 9/19/24 6:14 PM, Tom Lane wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
>> Oh, actually, I see that we are already validating the hash, but you can
>> create valid SCRAM-SHA-256 hashes that are really long.

You _can_, but it's up to a driver or a very determined user to do this,
as it involves creating a very long salt.

> So putting an
>> arbitrary limit (patch attached) is probably the correct path forward. I'd
>> also remove pg_authid's TOAST table while at it.
>
> Shouldn't we enforce the limit in every case in encrypt_password,
> not just this one? (I do agree that encrypt_password is an okay
> place to enforce it.)

+1; if there's any breakage, my guess is it would be on very long
plaintext passwords, but that would be from a very old upgrade?

> I think you will get pushback from a limit of 256 bytes --- I seem
> to recall discussion of actual use-cases where people were using
> strings of a couple of kB. Whatever the limit is, the error message
> had better cite it explicitly.

I think it's OK to be a bit generous with the limit. Also, currently oru
hashes are 256-bit (I know the above says byte), but this could increase
should we support larger hashes.

> Also, the ereport call needs an errcode.
> ERRCODE_PROGRAM_LIMIT_EXCEEDED is probably suitable.

Jonathan