Re: [PoC/RFC] Multiple passwords, interval expirations
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Gurjeet Singh <gurjeet@singh.im>, PostgreSQL Hackers
<pgsql-hackers@lists.postgresql.org>, Stephen Frost <sfrost@snowman.net>,
"Brindle, Joshua" <joshuqbr@amazon.com>, Jacob Champion
<jchampion@timescale.com>
Date: 2023-10-06T20:20:03Z
Lists: pgsql-hackers
On Fri, 2023-10-06 at 14:26 -0500, Nathan Bossart wrote: > I guess it's more of the latter. Perhaps one potential use case > would be > short-lived credentials that are created on demand. Such a password > might > only be valid for something like 15 minutes, and many users might > have the > ability to request a password for the database role. I don't know > whether > there is a ton of demand for such a use case, and it might already be > solvable by just creating separate roles. In any case, if there's > general > agreement that we only want to target the rotation use case, that's > fine by > me. The basic problem, as I see it, is: how do we keep users from accidentally dropping the wrong password? Generated unique names or numbers don't solve that problem. Auto-incrementing or a created-at timestamp solves it in the sense that you can at least look at a system view and see if there's a newer one, but it's a little awkward. A validity period is a good fit if all passwords have a validity period and we don't change it, but gets awkward otherwise. I'm also worried about two kinds of clutter: * old passwords not being garbage-collected * the identifier of the current password always changing (perhaps fine if it'a a "created at" ID?) Regards, Jeff Davis
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
MergeAttributes: convert pg_attribute back to ColumnDef before comparing
- 4d969b2f85e1 17.0 cited