Em qua., 15 de jan. de 2025 às 14:03, Peter Eisentraut
escreveu:
>
> On 14.01.25 15:14, Matheus Alcantara wrote:
> >> Attached is a fixup patch where I have tried to expand the documentation
> >> a bit in an attempt to clarify how to use this. Maybe check that what I
> >> wrote is correct.
> >
>
On 14.01.25 15:14, Matheus Alcantara wrote:
Attached is a fixup patch where I have tried to expand the documentation
a bit in an attempt to clarify how to use this. Maybe check that what I
wrote is correct.
It looks good to me, it's much clearer now. Thanks.
v4 attached with these fixes and a
Em ter., 14 de jan. de 2025 às 06:21, Peter Eisentraut
escreveu:
>
> On 09.01.25 16:22, Matheus Alcantara wrote:
> > Yeah, I also think that makes sense.
> >
> > I've made all changes on the attached v2.
>
> (This should probably have been v3, since you had already sent a v2
> earlier.)
>
Oops, so
On 09.01.25 16:22, Matheus Alcantara wrote:
Yeah, I also think that makes sense.
I've made all changes on the attached v2.
(This should probably have been v3, since you had already sent a v2
earlier.)
This all looks good to me.
Attached is a fixup patch where I have tried to expand the doc
Thanks for the review!
Em qua., 8 de jan. de 2025 às 07:49, Peter Eisentraut
escreveu:
>
> This patch is surprisingly compact and straightforward for providing
> such complex functionality.
>
> I have one major code comment that needs addressing:
>
> In src/interfaces/libpq/fe-auth-scram.c, there
This patch is surprisingly compact and straightforward for providing
such complex functionality.
I have one major code comment that needs addressing:
In src/interfaces/libpq/fe-auth-scram.c, there is:
+ memcpy(ClientKey, state->conn->scram_client_key_binary,
SCRAM_MAX_KEY_LEN);
Here y
On Wed, Dec 11, 2024 at 11:04 AM Matheus Alcantara
wrote:
> Em qua., 4 de dez. de 2024 às 20:39, Jacob Champion
> escreveu:
> > Sure, I'm not saying it's worse than plaintext. But a third
> > alternative might be actual pass-through SCRAM [1], where either you
> > expect the two servers to share
Em qua., 4 de dez. de 2024 às 20:39, Jacob Champion
escreveu:
>
> On Wed, Dec 4, 2024 at 3:05 PM Jelte Fennema-Nio wrote:
> > I only see advantages over the
> > alternative, which is copying the plaintext password around. In case
> > of compromise of the server, only the salt+verifier has to be r
On 04/12/24 20:05, Jelte Fennema-Nio wrote:
On Wed, 4 Dec 2024 at 23:11, Jacob Champion
wrote:
It makes me a little uneasy to give users a reason to copy identical
salts/verifiers around... But for e.g. a loopback connection, it seems
like there'd be no additional risk. Is that the target use c
Thanks for the comments!
On 04/12/24 19:11, Jacob Champion wrote:
This is achieved by storing the SCRAM ClientKey and ServerKey obtained
during client authentication with the backend. These keys are then
used to complete the SCRAM exchange between the backend and the fdw
server, eliminating the
On Wed, Dec 4, 2024 at 3:39 PM Jacob Champion
wrote:
> actual pass-through SCRAM
(This was probably not a helpful way to describe what I'm talking
about; the method here in the thread could be considered "actual
pass-through SCRAM" as well. Proxied SCRAM, maybe?)
--Jacob
On Wed, Dec 4, 2024 at 3:05 PM Jelte Fennema-Nio wrote:
> I only see advantages over the
> alternative, which is copying the plaintext password around. In case
> of compromise of the server, only the salt+verifier has to be rotated,
> not the actual user password.
Sure, I'm not saying it's worse
On Wed, 4 Dec 2024 at 23:11, Jacob Champion
wrote:
> It makes me a little uneasy to give users a reason to copy identical
> salts/verifiers around... But for e.g. a loopback connection, it seems
> like there'd be no additional risk. Is that the target use case?
I don't think that necessarily has
On Wed, Dec 4, 2024 at 10:45 AM Matheus Alcantara
wrote:
> This is achieved by storing the SCRAM ClientKey and ServerKey obtained
> during client authentication with the backend. These keys are then
> used to complete the SCRAM exchange between the backend and the fdw
> server, eliminating the nee
14 matches
Mail list logo
