Re: Raising the SCRAM iteration count
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Michael Paquier <michael@paquier.xyz>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
Andres Freund <andres@anarazel.de>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-03-03T22:13:36Z
Lists: pgsql-hackers
Attachments
- v6-0001-Make-SCRAM-iteration-count-configurable.patch (application/octet-stream) patch v6-0001
> On 27 Feb 2023, at 08:06, Michael Paquier <michael@paquier.xyz> wrote: > + conn->scram_sha_256_iterations = atoi(value); > + } > This should match on "scram_iterations", which is the name of the > GUC. Fixed. > Would the long-term plan be to use multiple variables in conn if > we ever get to <method>:<iterations> that would require more parsing? I personally don't think we'll see more than 2 or at most 3 values so parsing that format shouldn't be a problem, but it can always be revisited if/when we get there. > Perhaps there should be a test with \password to make sure that libpq > gets the call when the GUC is updated by a SET command? That would indeed be nice, but is there a way to do this without a complicated pump TAP expression? I was unable to think of a way but I might be missing something? -- Daniel Gustafsson
Commits
-
Test SCRAM iteration changes with psql \password
- bf5a894c5571 16.0 landed
-
Make SCRAM iteration count configurable
- b577743000cd 16.0 landed