On Sun, Mar 26, 2023 at 11:14:37PM +0200, Daniel Gustafsson wrote:
> > On 25 Mar 2023, at 01:56, Michael Paquier wrote:
> >
> > On Fri, Mar 24, 2023 at 09:56:29AM +0100, Daniel Gustafsson wrote:
> >> I've actually ripped out the test in question in the attached v9 to have it
> >> ready and
> On 25 Mar 2023, at 01:56, Michael Paquier wrote:
>
> On Fri, Mar 24, 2023 at 09:56:29AM +0100, Daniel Gustafsson wrote:
>> I've actually ripped out the test in question in the attached v9 to have it
>> ready and building green in CFbot.
>
> While reading through v9, I have noticed a few
On Fri, Mar 24, 2023 at 09:56:29AM +0100, Daniel Gustafsson wrote:
> I've actually ripped out the test in question in the attached v9 to have it
> ready and building green in CFbot.
While reading through v9, I have noticed a few things.
+-- Changing the SCRAM iteration count
+SET
> On 24 Mar 2023, at 00:33, Michael Paquier wrote:
>
> On Thu, Mar 23, 2023 at 10:46:56PM +0100, Daniel Gustafsson wrote:
>> I'm fairly convinced it's a timeout in the interactive psql session. Given
>> how
>> ugly the use of that is I'm sort of waiting for Andres' refactoring patch
>> [0] to
On Thu, Mar 23, 2023 at 10:46:56PM +0100, Daniel Gustafsson wrote:
> I'm fairly convinced it's a timeout in the interactive psql session. Given
> how
> ugly the use of that is I'm sort of waiting for Andres' refactoring patch [0]
> to
> commit this such that I can rewrite the test in a saner
> On 22 Mar 2023, at 04:14, Gregory Stark (as CFM) wrote:
> On Tue, 14 Mar 2023 at 14:54, Gregory Stark (as CFM)
> wrote:
>>
>> CFBot is failing with this test failure... I'm not sure if this just
>> represents a timing dependency or a bad test or what?
>
> CFBot is now consistently showing
On Tue, 14 Mar 2023 at 14:54, Gregory Stark (as CFM)
wrote:
>
> CFBot is failing with this test failure... I'm not sure if this just
> represents a timing dependency or a bad test or what?
CFBot is now consistently showing these test failures. I think there
might actually be a problem here?
>
CFBot is failing with this test failure... I'm not sure if this just
represents a timing dependency or a bad test or what?
[09:44:49.937] --- stdout ---
[09:44:49.937] # executing test in
/tmp/cirrus-ci-build/build-32/testrun/authentication/001_password
group authentication test 001_password
> On 9 Mar 2023, at 08:09, Michael Paquier wrote:
>
> On Wed, Mar 08, 2023 at 05:21:20PM +0900, Michael Paquier wrote:
>> On Wed, Mar 08, 2023 at 09:07:36AM +0100, Daniel Gustafsson wrote:
>>> AFAIK a TAP test with psql_interactive is the only way to do this so that's
>>> what I've implemented.
On Wed, Mar 08, 2023 at 05:21:20PM +0900, Michael Paquier wrote:
> On Wed, Mar 08, 2023 at 09:07:36AM +0100, Daniel Gustafsson wrote:
>> AFAIK a TAP test with psql_interactive is the only way to do this so that's
>> what I've implemented.
I cannot think of a better idea than what you have here,
On Wed, Mar 08, 2023 at 09:07:36AM +0100, Daniel Gustafsson wrote:
> No, I just did not think it was possible to feed input to the interactive
> \password prompt with a normal pg_regress SQL file test. If you are able to
> do
> that I'd love to see an example.
>
> AFAIK a TAP test with
> On 8 Mar 2023, at 08:48, Michael Paquier wrote:
>
> On Tue, Mar 07, 2023 at 02:03:05PM +0100, Daniel Gustafsson wrote:
>> On 7 Mar 2023, at 09:26, Daniel Gustafsson wrote:
>>> Right, what I meant was: can a pg_regress sql/expected test drive a psql
>>> interactive prompt? Your comments
On Tue, Mar 07, 2023 at 02:03:05PM +0100, Daniel Gustafsson wrote:
> On 7 Mar 2023, at 09:26, Daniel Gustafsson wrote:
>> Right, what I meant was: can a pg_regress sql/expected test drive a psql
>> interactive prompt? Your comments suggested using password.sql so I was
>> curious if I was
> On 7 Mar 2023, at 09:26, Daniel Gustafsson wrote:
> Right, what I meant was: can a pg_regress sql/expected test drive a psql
> interactive prompt? Your comments suggested using password.sql so I was
> curious if I was missing a neat trick for doing this.
The attached v7 adds a TAP test for
> On 7 Mar 2023, at 05:53, Michael Paquier wrote:
>
> On Fri, Mar 03, 2023 at 11:13:36PM +0100, Daniel Gustafsson wrote:
>> 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
>>
On Fri, Mar 03, 2023 at 11:13:36PM +0100, Daniel Gustafsson wrote:
> 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?
A SET command refreshes immediately the cache information
> On 27 Feb 2023, at 08:06, Michael Paquier 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 : that would
On Thu, Feb 23, 2023 at 03:10:05PM +0100, Daniel Gustafsson wrote:
> In fixing the CFBot test error in the previous version I realized through
> off-list discussion that the GUC name was badly chosen. Incorporating the
> value of another GUC in the name is a bad idea, so the attached version
>
> On 22 Feb 2023, at 18:21, Jonathan S. Katz wrote:
> On 2/22/23 8:39 AM, Daniel Gustafsson wrote:
>> The attached is a rebase on top of master with no other additional hacking
>> done
>> on top of the above review comments.
>
> Generally LGTM. I read through earlier comments (sorry I missed
On 2/22/23 8:39 AM, Daniel Gustafsson wrote:
On 17 Dec 2022, at 04:27, Michael Paquier wrote:
Superuser-only GUCs should be documented as such, or do you intend to
make it user-settable like I suggested upthread :) ?
I don't really have strong feelings, so I reverted to being
> On 17 Dec 2022, at 04:27, Michael Paquier wrote:
>
> On Thu, Dec 15, 2022 at 12:09:15PM +0100, Daniel Gustafsson wrote:
>>> On 15 Dec 2022, at 00:52, Michael Paquier wrote:
>>> conn->in_hot_standby = PG_BOOL_UNKNOWN;
>>> + conn->scram_iterations = SCRAM_DEFAULT_ITERATIONS;
>>>
>>>
On Thu, Dec 15, 2022 at 12:09:15PM +0100, Daniel Gustafsson wrote:
>> On 15 Dec 2022, at 00:52, Michael Paquier wrote:
>>conn->in_hot_standby = PG_BOOL_UNKNOWN;
>> + conn->scram_iterations = SCRAM_DEFAULT_ITERATIONS;
>>
>> s/SCRAM_DEFAULT_ITERATIONS/SCRAM_SHA_256_DEFAULT_ITERATIONS/ and
>>
> On 15 Dec 2022, at 00:52, Michael Paquier wrote:
>conn->in_hot_standby = PG_BOOL_UNKNOWN;
> + conn->scram_iterations = SCRAM_DEFAULT_ITERATIONS;
>
> s/SCRAM_DEFAULT_ITERATIONS/SCRAM_SHA_256_DEFAULT_ITERATIONS/ and
> s/scram_iterations/scram_sha_256_interations/ perhaps?
Distinct
> On 14 Dec 2022, at 19:59, Jonathan S. Katz wrote:
> On 12/14/22 6:25 AM, Daniel Gustafsson wrote:
>>> On 14 Dec 2022, at 02:00, Michael Paquier wrote:
>>> So, you mean that the GUC should be named like password_iterations,
>>> taking a grammar with a list like 'scram-sha-256=4096,algo2=5000'?
On 12/14/22 6:52 PM, Michael Paquier wrote:
On Wed, Dec 14, 2022 at 01:59:04PM -0500, Jonathan S. Katz wrote:
HA-256 that we will just need to pick up?
The attached v2 has the GUC rename and a change to GUC_REPORT such that the
frontend can use the real value rather than the default. I kept
On Wed, Dec 14, 2022 at 01:59:04PM -0500, Jonathan S. Katz wrote:
> On 12/14/22 6:25 AM, Daniel Gustafsson wrote:
>> I was thinking about it but opted for the simpler approach of a GUC name with
>> the algorithm baked into it: scram_sha256_iterations. It doesn't seem all
>> that
>> likely that
On 12/14/22 6:25 AM, Daniel Gustafsson wrote:
On 14 Dec 2022, at 02:00, Michael Paquier wrote:
On Tue, Dec 13, 2022 at 12:17:58PM +0100, Daniel Gustafsson wrote:
It does raise an interesting point though, if we in the future add suppprt for
SCRAM-SHA-512 (which seems reasonable to do) it's
> On 14 Dec 2022, at 02:00, Michael Paquier wrote:
>
> On Tue, Dec 13, 2022 at 12:17:58PM +0100, Daniel Gustafsson wrote:
>> It does raise an interesting point though, if we in the future add suppprt
>> for
>> SCRAM-SHA-512 (which seems reasonable to do) it's not good enough to have a
>> single
On Tue, Dec 13, 2022 at 12:17:58PM +0100, Daniel Gustafsson wrote:
> It does raise an interesting point though, if we in the future add suppprt for
> SCRAM-SHA-512 (which seems reasonable to do) it's not good enough to have a
> single GUC for SCRAM iterations; we'd need to be able to set the
> On 12 Dec 2022, at 15:47, Jonathan S. Katz wrote:
> To throw on a bit of paint, if we do change it, we should likely follow what
> would come out in a RFC.
>
> While the SCRAM-SHA-512 RFC is still in draft[1], the latest draft it
> contains a "SHOULD" recommendation of 1, which was
On 12/9/22 7:15 PM, Andres Freund wrote:
Hi,
On 2022-12-09 11:55:07 +0100, Daniel Gustafsson wrote:
Our current hardcoded value for iteration count is 4096, which is based on a
recommendation from RFC 7677. This is however the lower end of the scale, and
is related to computing power in 2015
On Sun, Dec 11, 2022 at 12:46:23AM +0100, Daniel Gustafsson wrote:
> SCRAM with an iteration count of 1 still provides a lot of benefits over md5,
> so if we can make those comparable in performance then that could be a way
> forward (with the tradeoffs properly documented).
Okay, it looks like
> On 10 Dec 2022, at 01:15, Andres Freund wrote:
> On 2022-12-09 11:55:07 +0100, Daniel Gustafsson wrote:
>> The attached introduces a scram_iteration_count GUC with a default of 15000
>> (still conservative, from RFC7677) and a minimum of 4096. Since the
>> iterations
>> are stored per secret
Hi,
On 2022-12-09 11:55:07 +0100, Daniel Gustafsson wrote:
> Our current hardcoded value for iteration count is 4096, which is based on a
> recommendation from RFC 7677. This is however the lower end of the scale, and
> is related to computing power in 2015 generation handheld devices. The
>
On Fri, Dec 09, 2022 at 05:50:00PM +0200, Heikki Linnakangas wrote:
>> The attached introduces a scram_iteration_count GUC with a default of 15000
>> (still conservative, from RFC7677) and a minimum of 4096. Since the
>> iterations
>> are stored per secret it can be altered with backwards
On 09/12/2022 12:55, Daniel Gustafsson wrote:
In the thread about user space SCRAM functions [0] I mentioned that it might be
wise to consider raising our SCRAM iteration count. The iteration count is an
important defence against brute-force attacks.
Our current hardcoded value for iteration
In the thread about user space SCRAM functions [0] I mentioned that it might be
wise to consider raising our SCRAM iteration count. The iteration count is an
important defence against brute-force attacks.
Our current hardcoded value for iteration count is 4096, which is based on a
recommendation
37 matches
Mail list logo
