On Tue, Jul 13, 2021 at 10:41:01PM +, Jacob Champion wrote:
> Just to make sure -- do we want to export the fe-auth-sasl.h header as
> opposed to forward-declaring the pg_fe_sasl_mech struct?
Installing fe-auth-sasl.h has the advantage to make the internals of
the callbacks available to applic
On Tue, 2021-07-13 at 22:41 +, Jacob Champion wrote:
> On Tue, 2021-07-13 at 19:31 +0900, Michael Paquier wrote:
> > On Tue, Jul 13, 2021 at 12:41:27PM +0300, Mikhail Kulagin wrote:
> > >
> > > I think the new fe-auth-sasl.h file should be installed too.
> > > Correction proposal in the attach
On Tue, 2021-07-13 at 19:31 +0900, Michael Paquier wrote:
> On Tue, Jul 13, 2021 at 12:41:27PM +0300, Mikhail Kulagin wrote:
> > I got an error while building one of the extensions.
> > /home/mkulagin/pg-install/postgresql-master/include/internal/libpq-int.h:44:10:
> > fatal error: fe-auth-sasl.h:
On Tue, Jul 13, 2021 at 12:41:27PM +0300, Mikhail Kulagin wrote:
> I got an error while building one of the extensions.
> /home/mkulagin/pg-install/postgresql-master/include/internal/libpq-int.h:44:10:
> fatal error: fe-auth-sasl.h: No such file or directory
> #include "fe-auth-s
Hello, hackers!
I got an error while building one of the extensions.
/home/mkulagin/pg-install/postgresql-master/include/internal/libpq-int.h:44:10:
fatal error: fe-auth-sasl.h: No such file or directory
#include "fe-auth-sasl.h"
^~~~
I
On Tue, Jul 13, 2021 at 12:01:46AM +, Jacob Champion wrote:
> Ah, right. I think the (!done && !success) case is probably indicative
> of an API smell, but that's probably something to clean up in a future
> pass.
Yeah, agreed. I feel that it would should be cleaner to replace those
two boole
On Sun, 2021-07-11 at 13:16 +0900, Michael Paquier wrote:
> On Fri, Jul 09, 2021 at 11:31:48PM +, Jacob Champion wrote:
> > On Thu, 2021-07-08 at 16:27 +0900, Michael Paquier wrote:
> > > + * outputlen: The length (0 or higher) of the client response
> > > buffer,
> > > + *
On Fri, Jul 09, 2021 at 11:31:48PM +, Jacob Champion wrote:
> On Thu, 2021-07-08 at 16:27 +0900, Michael Paquier wrote:
>> + * outputlen: The length (0 or higher) of the client response
>> buffer,
>> + * invalid if output is NULL.
>
> nitpick: maybe "ignor
On Thu, 2021-07-08 at 16:27 +0900, Michael Paquier wrote:
> I agree that this looks like an improvement in terms of the
> expectations behind a SASL mechanism, so I have done the attached to
> strengthen a bit all those checks. However, I don't really see a
> point in back-patching any of that, as
On Wed, Jul 07, 2021 at 03:07:14PM +, Jacob Champion wrote:
> That's correct. But the client may not simply ignore the challenge and
> keep the exchange open waiting for a new one, as pg_SASL_continue()
> currently allows. That's what my TODO is referring to.
I have been looking more at your t
On Wed, 2021-07-07 at 14:08 +0900, Michael Paquier wrote:
> On Tue, Jul 06, 2021 at 06:20:49PM +, Jacob Champion wrote:
> > On Mon, 2021-07-05 at 17:17 +0900, Michael Paquier wrote:
> >
> > > Hmm. Does the RFCs tell us anything about that?
> >
> > Just in general terms:
> >
> > >Each au
On Tue, Jul 06, 2021 at 06:20:49PM +, Jacob Champion wrote:
> On Mon, 2021-07-05 at 17:17 +0900, Michael Paquier wrote:
> Each name must be null-terminated, not just null-separated. That way
> the list of names ends with an empty string:
>
> name-one\0 <- added by the mechanis
On Mon, 2021-07-05 at 17:17 +0900, Michael Paquier wrote:
> On Wed, Jun 30, 2021 at 10:30:12PM +, Jacob Champion wrote:
> > Done in v3, with a second patch for the code motion.
>
> I have gone through that, tweaking the documentation you have added as
> that's the meat of the patch, reworking
On Wed, Jun 30, 2021 at 10:30:12PM +, Jacob Champion wrote:
> Done in v3, with a second patch for the code motion.
I have gone through that, tweaking the documentation you have added as
that's the meat of the patch, reworking a bit the declarations of the
callbacks (no need for several typedef
On Sat, 2021-06-26 at 09:47 +0900, Michael Paquier wrote:
> On Fri, Jun 25, 2021 at 11:40:33PM +, Jacob Champion wrote:
> > I can definitely move it (into, say, auth-sasl.c?). I'll probably do
> > that in a second commit, though, since keeping it in place during the
> > refactor makes the revie
On Fri, Jun 25, 2021 at 11:40:33PM +, Jacob Champion wrote:
> I can definitely move it (into, say, auth-sasl.c?). I'll probably do
> that in a second commit, though, since keeping it in place during the
> refactor makes the review easier IMO.
auth-sasl.c is a name consistent with the existing
On Wed, 2021-06-23 at 16:38 +0900, Michael Paquier wrote:
> On Tue, Jun 22, 2021 at 10:37:29PM +, Jacob Champion wrote:
> > Currently, the SASL logic is tightly coupled to the SCRAM
> > implementation. This patch untangles the two, by introducing callback
> > structs for both the frontend and b
On Tue, Jun 22, 2021 at 10:37:29PM +, Jacob Champion wrote:
> Currently, the SASL logic is tightly coupled to the SCRAM
> implementation. This patch untangles the two, by introducing callback
> structs for both the frontend and backend.
The approach to define and have a set callbacks feels nat
(This is split off from my work on OAUTHBEARER [1].)
Currently, the SASL logic is tightly coupled to the SCRAM
implementation. This patch untangles the two, by introducing callback
structs for both the frontend and backend.
In the original thread, Michael Paquier commented:
> + /* TODO
19 matches
Mail list logo
