public inbox for [email protected]  

help / color / mirror / Atom feed

From: Nathan Bossart <[email protected]>
To: Tom Lane <[email protected]>
Cc: Jonathan S. Katz <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Should rolpassword be toastable?
Date: Thu, 3 Oct 2024 17:17:01 -0500
Message-ID: <Zv8X3YVzuPfh1Fht@nathan> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<Zuzh6Nq750L9BZn5@nathan>
	<[email protected]>
	<[email protected]>
	<Zu2eT2H8OT3OXauc@nathan>
	<[email protected]>
	<Zu8r0oO0Vi0FxdpB@nathan>
	<Zv8MTMy87pRlRqD_@nathan>
	<[email protected]>

On Thu, Oct 03, 2024 at 05:39:06PM -0400, Tom Lane wrote:
> I agree with the idea that complaining about the password being too
> long is far more intelligible than that.  Another problem with
> leaving it as it stands in HEAD is that the effective limit is now
> platform-specific, if not indeed dependent on the phase of the moon
> (or at least, the other contents of the pg_authid row).  I fear it
> would be very easy to construct cases where a password is accepted
> on one machine but fails with "row is too big" on another.  A
> uniform limit seems much less fraught with surprises.

I don't mind proceeding with the patch if there is strong support for it.
I wavered only because it's hard to be confident that we are choosing the
right limit.  AFAICT 256 bytes ought to be sufficient to avoid "row is too
big" errors independent of BLCKSZ today, but maybe someone will add another
varlena column in the future that breaks it.  Or maybe we add a new
password hashing method that produces longer strings.  Or maybe someone is
doing something really out there like storing additional information in the
salt.  I don't have any reason to believe that any of these things are
happening or are likely to happen anytime soon, but they seem similar in
likelihood to someone building a custom driver that generates ginormous
hashes.  But I can also buy the argument that none of this is a strong
enough reason to avoid making the error message nicer...

-- 
nathan

view thread (17+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Should rolpassword be toastable?
  In-Reply-To: <Zv8X3YVzuPfh1Fht@nathan>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox