Re: User functions for building SCRAM secrets - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: User functions for building SCRAM secrets
Date
Msg-id CAAWbhmiOMgXFVAUZhVkXPA2+9-Wsjyxm7WXyEsy2viFDB-E0Sg@mail.gmail.com
Whole thread Raw
In response to Re: User functions for building SCRAM secrets  (Jacob Champion <jchampion@timescale.com>)
Responses Re: User functions for building SCRAM secrets
List pgsql-hackers
On Tue, Nov 1, 2022 at 4:02 PM Jacob Champion <jchampion@timescale.com> wrote:
> I guess I have fewer problems with this use case in theory, but I'm
> wondering if better client-side support might also solve this one as
> well, without the additional complication. Is there a reason it would
> not?

To expand on this question, after giving it some more thought:

It seems to me that the use case here is extremely similar to the one
being tackled by Peter E's client-side encryption [1]. People want to
write SQL to perform a cryptographic operation using a secret, and
then send the resulting ciphertext (or in this case, a one-way hash)
to the server, but ideally the server should not actually have the
secret.

I don't think it's helpful for me to try to block progress on this
patchset behind the other one. But is there a way for me to help this
proposal skate in the same general direction? Could Peter's encryption
framework expand to fit this case in the future?

Thanks,
--Jacob

[1] https://www.postgresql.org/message-id/flat/89157929-c2b6-817b-6025-8e4b2d89d88f%40enterprisedb.com



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Commit fest 2022-11
Next
From: Melanie Plageman
Date:
Subject: Re: Split index and table statistics into different types of stats