> On 21 Jan 2025, at 17:46, Jacob Champion
> wrote:
> Done that way in v43.
I've spent some time staring at, and testing, 0001, 0002 and 0003 with the
intent of getting them in to pave the way for the end goal of getting 0004 in.
In general I would say they are ready, I only have a small nitpic
> On 21 Jan 2025, at 01:40, Jacob Champion
> wrote:
> On Mon, Jan 20, 2025 at 2:10 PM Daniel Gustafsson wrote:
>> + /* Done. Tear down the async implementation. */
>> + conn->cleanup_async_auth(conn);
>> + conn->cleanup_async_auth = NULL;
>> + Assert(conn->altsock == PGINVALID_SOCKET);
On Mon, Jan 20, 2025 at 4:40 PM Jacob Champion
wrote:
> But I can add a comment to the assignment to try to explain. I don't
> know what the likelihood of landing code that trips that assertion is,
> but an explicit assignment would at least stop problems from
> cascading.
On second thought, I ca
On Mon, Jan 20, 2025 at 2:10 PM Daniel Gustafsson wrote:
> + /*
> + * The mechanism should have set up the necessary callbacks; all we
> + * need to do is signal the caller.
> + */
> + *async = true;
> + return STATUS_OK;
> Is it worth adding assertions here to ensure that everything has
> On 14 Jan 2025, at 00:21, Jacob Champion
> wrote:
> - 0001 moves PG_MAX_AUTH_TOKEN_LENGTH, as discussed upthread
> - 0002 handles the non-OAuth-specific changes to require_auth (0005
> now highlights the OAuth-specific pieces)
> - 0003 adds SASL_ASYNC and its handling code
I was reading these
On Tue, Jan 14, 2025 at 6:00 AM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Mon, Jan 13, 2025 at 3:21 PM Jacob Champion
> wrote:
> > Next email will discuss the architectural bug that Kashif found.
>
> Okay, here goes. A standard OAuth connection attempt looks like this
> (oh, I
On Mon, Jan 13, 2025 at 3:21 PM Jacob Champion
wrote:
> Next email will discuss the architectural bug that Kashif found.
Okay, here goes. A standard OAuth connection attempt looks like this
(oh, I hope Gmail doesn't mangle it):
IssuerUserlibpq Backend
|||
On 09.01.25 20:18, Jacob Champion wrote:
It'd be sad to copy-paste the API bug into a new place, though. If
we're going to disconnect this API from SOCKET, can we use uintptr_t
instead on Windows? If someone eventually adds an alternative to
PQsocket(), as Tom suggested in [2], it'd be nice not t
> On 9 Jan 2025, at 23:35, Jacob Champion
> wrote:
>
> On Thu, Jan 9, 2025 at 12:40 PM Daniel Gustafsson wrote:
>> + * Find the start of the .well-known prefix. IETF rules state this must be
>> + * at the beginning of the path component, but OIDC defined it at the end
>> + * instead, so we have
On Thu, Jan 9, 2025 at 12:40 PM Daniel Gustafsson wrote:
> + * Find the start of the .well-known prefix. IETF rules state this must be
> + * at the beginning of the path component, but OIDC defined it at the end
> + * instead, so we have to search for it anywhere.
> I was looking for a reference f
> On 20 Dec 2024, at 02:00, Jacob Champion
> wrote:
> v40 also contains:
A few small comments on v40 rather than saving up for a longer email:
+ ereport(LOG, errmsg("Internal error in OAuth validator module"));
Tiny nitpick, the errmsg() should start with lowercase 'i'.
+ libpq_append_conn_
On Thu, Jan 9, 2025 at 8:17 AM Peter Eisentraut wrote:
>
> Maybe it would work to just use plain "int" as the type here. Any
> socket number must fit into int anyway in order for PQsocket() to be
> able to return it. The way I understand Windows socket handles, this
> should work.
Looks like it
On 08.01.25 21:29, Jacob Champion wrote:
It'd also couple clients against libpq-int.h, so they'd have to
remember to recompile every release. I'm worried that'd cause a bunch
of ABI problems...
Couldn't that function use PQsocket() to get at the actual socket from
the PGconn handle?
It's an out
On Wed, Jan 8, 2025 at 11:37 AM Peter Eisentraut wrote:
> I don't know what you mean by
> "accept in the code". I would agree with "tolerate some inconsistency"
> in the code but not with, like, create alias names for all the interface
> names.
"Tolerate inconsistency" was what I had in mind. So
On 07.01.25 23:24, Jacob Champion wrote:
On Thu, Jan 2, 2025 at 2:11 AM Peter Eisentraut wrote:
There is a mix of using "URL" and "URI" throughout the patch. I tried
to look up in the source material (RFCs) what the correct use would
be, but even they are mixing it in nonobvious ways. Maybe t
On Tue, Jan 7, 2025 at 2:24 PM Jacob Champion
wrote:
> Along those lines, though, Michael Paquier suggested that maybe I
> could pull the require_auth prefactoring up to the front of the
> patchset. That might look a bit odd until OAuth support lands, since
> it won't be adding any new useful valu
On Wed, Jan 8, 2025 at 3:21 AM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Fri, Dec 20, 2024 at 2:21 PM Daniel Gustafsson wrote:
> >
> > > On 20 Dec 2024, at 02:00, Jacob Champion <
> jacob.champ...@enterprisedb.com> wrote:
> >
> > Thanks for the new version, I was doing a v39 r
On Thu, Jan 2, 2025 at 2:11 AM Peter Eisentraut wrote:
> There is a mix of using "URL" and "URI" throughout the patch. I tried
> to look up in the source material (RFCs) what the correct use would
> be, but even they are mixing it in nonobvious ways. Maybe this is
> just hopelessly confused, or
On Fri, Dec 20, 2024 at 2:21 PM Daniel Gustafsson wrote:
>
> > On 20 Dec 2024, at 02:00, Jacob Champion
> > wrote:
>
> Thanks for the new version, I was doing a v39 review but I'll roll that over
> into a v40 review now.
(Sorry for the rug pull!)
> As I was reading I was trying to identify par
On 20.12.24 02:00, Jacob Champion wrote:
v40 also contains:
- explicit testing for connect_timeout compatibility
- support for require_auth=oauth, including compatibility with
require_auth=!scram-sha-256
- the ability for a validator to set authn_id even if the token is not
authorized, for audita
> On 20 Dec 2024, at 02:00, Jacob Champion
> wrote:
Thanks for the new version, I was doing a v39 review but I'll roll that over
into a v40 review now.
As I was reading I was trying to identify parts can be broken out and committed
ahead of time. This not only to trim down size, but mostly to
On Sun, Dec 15, 2024 at 2:18 PM Daniel Gustafsson wrote:
> I think we should, I just now experimented with setting the server major
> version (backed by PG_VERSION_NUM) in the callback struct and added a simple
> test. I'm not sure if there is a whole lot more we need, maybe an opaque
> integer f
> On 5 Dec 2024, at 19:29, Jacob Champion
> wrote:
> Seems good. I think this part of the API is going to need an
> ABI-compatibility pass, too. For example, do we want a module to
> allocate the result struct itself (which locks in the struct length)?
> And should we have a MAGIC_NUMBER of some
Thanks for the updated version, it's really starting to take good shape. A few
small comments on v37 from a a first quick skim-through:
+ if (!strcmp(key, AUTH_KEY))
+ if (*expected_bearer && !strcmp(token, expected_bearer))
Nitpickery but these should be (strcmp(xxx) == 0) to match p
> On 21 Nov 2024, at 19:51, Jacob Champion
> wrote:
>
> On Tue, Nov 19, 2024 at 3:05 AM Peter Eisentraut wrote:
>> Personally, I'm not even a fan of the -Dssl/--with-ssl system. I'm more
>> attached to --with-openssl.
In hindsight, --with-ssl was prematurely pulled out from the various TLS
ba
On Tue, Nov 19, 2024 at 3:05 AM Peter Eisentraut wrote:
> Personally, I'm not even a fan of the -Dssl/--with-ssl system. I'm more
> attached to --with-openssl. But if you want to stick with that, a more
> suitable naming would be something like, say, --with-httplib=curl, which
> means, use curl
On 12.11.24 22:47, Jacob Champion wrote:
On Fri, Nov 8, 2024 at 1:21 AM Peter Eisentraut wrote:
I find the way the installation options are structured a bit odd. I
would have expected --with-libcurl and -Dlibcurl (or --with-curl and
-Dcurl). These build options usually just say, use this libr
On Tue, Nov 12, 2024 at 1:47 PM Jacob Champion
wrote:
> On Fri, Nov 8, 2024 at 1:21 AM Peter Eisentraut wrote:
> > Also, shouldn't [oauth_validator_library] be an hba option instead? What
> > if you want to
> > use different validators for different connections?
>
> Yes. This is again the multi
On Fri, Nov 8, 2024 at 1:21 AM Peter Eisentraut wrote:
> Assorted review comments from me:
Thank you! I will cherry-pick some responses here and plan to address
the rest in a future patchset.
> trust_validator_authz: Personally, I'm not a fan of the "authz" and
> "authn" abbreviations. I know t
On 06.11.24 00:33, Jacob Champion wrote:
Done in v36, attached.
Assorted review comments from me:
Everything in the commit message between
= Debug Mode =
and
Several TODOs:
should be moved to the documentation. In some cases, it already is,
but it doesn't always have the same leve
On Tue, Nov 5, 2024 at 3:33 PM Jacob Champion
wrote:
> Done in v36, attached.
Forgot to draw attention to this part:
> +# XXX libcurl must link after libgssapi_krb5 on FreeBSD to avoid
> segfaults
> +# during gss_acquire_cred(). This is possibly related to Curl's Heimdal
> +# depend
On Sun, Nov 3, 2024 at 9:00 PM jian he wrote:
> The above Assert looks very wrong to me.
I can switch to Assert(false) if that's preferred, but it makes part
of the libc assert() report useless. (I wish we had more fluent ways
to say "this shouldn't happen, but if it does, we still need to get
ou
> On 4 Nov 2024, at 06:00, jian he wrote:
> + if (cnt != 1)
> + {
> + /*
> + * Either the lexer screwed up or our assumption above isn't true, and
> + * either way a developer needs to take a look.
> + */
> + Assert(cnt == 1);
> + return 1; /* don't fall through in release builds */
> + }
> The
Hi there.
zero knowledge of Oath, just reading through the v35-0001.
forgive me if my comments are naive.
+static int
+parse_interval(struct async_ctx *actx, const char *interval_str)
+{
+ double parsed;
+ int cnt;
+
+ /*
+ * The JSON lexer has already validated the number, which is stricter than
On Thu, Oct 31, 2024 at 4:05 AM Antonin Houska wrote:
> > > And regardless, the library appears to be loaded by every backend during
> > > authentication. Why isn't it loaded by postmaster like libraries listed
> > > in
> > > shared_preload_libraries? fork() would then ensure that the backe
Jacob Champion wrote:
> On Thu, Oct 17, 2024 at 10:51 PM Antonin Houska wrote:
> > * oauth_validator_library is defined as PGC_SIGHUP - is that intentional?
>
> Yes, I think it's going to be important to let DBAs migrate their
> authentication modules without a full restart. That probably deser
On Tue, Oct 29, 2024 at 10:41 AM Daniel Gustafsson wrote:
> Question is though, if we added PAM
> today would we have done the same?
I assume so; the client can't tell PAM apart from LDAP or any other
plaintext method. (In the same vein, the server can't tell if the
client uses libcurl to grab a
> On 29 Oct 2024, at 17:40, Jacob Champion
> wrote:
>
> On Tue, Oct 29, 2024 at 3:52 AM Daniel Gustafsson wrote:
>> Currently we don't support any conditional compilation which only affects
>> backend or frontend, all --without-XXX flags turn it off for both.
>
> I don't think that's strictly
On Tue, Oct 29, 2024 at 3:52 AM Daniel Gustafsson wrote:
> Currently we don't support any conditional compilation which only affects
> backend or frontend, all --without-XXX flags turn it off for both.
I don't think that's strictly true; see --with-pam which affects only
server-side code, since t
> On 28 Oct 2024, at 17:09, Jacob Champion
> wrote:
> On Mon, Oct 28, 2024 at 6:24 AM Daniel Gustafsson wrote:
>> Looking more at the patchset I think we need to apply conditional compilation
>> of the backend for oauth like how we do with other opt-in schemes in
>> configure
>> and meson. Th
On Mon, Oct 28, 2024 at 6:24 AM Daniel Gustafsson wrote:
> > On 25 Oct 2024, at 20:22, Jacob Champion
> > wrote:
>
> > I have combed almost all of Daniel's feedback backwards into the main
> > patch (just the new bzero code remains, with the open question
> > upthread),
>
> Re-reading I can't se
> On 25 Oct 2024, at 20:22, Jacob Champion
> wrote:
> I have combed almost all of Daniel's feedback backwards into the main
> patch (just the new bzero code remains, with the open question
> upthread),
Re-reading I can't see a vector there, I guess I am just scarred from what
seemed to be harml
On Fri, Oct 18, 2024 at 4:38 AM Daniel Gustafsson wrote:
> In validate() it seems to me we should clear out ret->authn_id on failure to
> pair belts with suspenders. Fixed by calling explicit_bzero on it in the error
> path.
The new hunk says:
> cleanup:
> /*
> * Clear and free the vali
On Thu, Oct 17, 2024 at 10:51 PM Antonin Houska wrote:
> This is the 1st round, based on reading the code. I'll continue paying
> attention to the project and possibly post some more comments in the future.
Thanks again for the reviews!
> * Information on the new method should be added to pg_hba
Antonin Houska wrote:
> I'd like to play with the code a bit and provide some review before or during
> the next CF. That will probably generate some more questions.
This is the 1st round, based on reading the code. I'll continue paying
attention to the project and possibly post some more commen
On 15.10.24 20:10, Jacob Champion wrote:
On Tue, Oct 15, 2024 at 11:00 AM Alexander Lakhin wrote:
I've discovered that starting from 0785d1b8b,
make check -C src/bin/pg_combinebackup
fails under Valgrind, with the following diagnostics:
Yep, sorry for that (and thanks for the report!). It's c
On Tue, Oct 15, 2024 at 11:00 AM Alexander Lakhin wrote:
> I've discovered that starting from 0785d1b8b,
> make check -C src/bin/pg_combinebackup
> fails under Valgrind, with the following diagnostics:
Yep, sorry for that (and thanks for the report!). It's currently
tracked over at [1], but I sho
Hello Peter,
11.09.2024 10:37, Peter Eisentraut wrote:
This has been committed.
I've discovered that starting from 0785d1b8b,
make check -C src/bin/pg_combinebackup
fails under Valgrind, with the following diagnostics:
2024-10-15 14:29:52.883 UTC [3338981] 002_compare_backups.pl STATEMENT:
On Tue, Oct 8, 2024 at 3:46 AM Antonin Houska wrote:
> Perhaps I understand now. I use getmail [2] to retrieve email messages from my
> Google account. What made me confused is that the getmail application,
> although installed on my workstation (and thus the bearer token it eventually
> gets cont
Jacob Champion wrote:
> On Mon, Sep 30, 2024 at 6:38 AM Antonin Houska wrote:
> >
> > Are you sure you can legitimately acquire the bearer token containing my
> > email
> > address?
>
> Yes. In general that's how OpenID-based "Sign in with "
> works. All those third-party services are running
On Mon, Sep 30, 2024 at 6:38 AM Antonin Houska wrote:
>
> Jacob Champion wrote:
>
> > On Fri, Sep 27, 2024 at 10:58 AM Antonin Houska wrote:
> > That's why people are so pedantic about saying that OAuth is an
> > authorization framework and not an authentication framework.
>
> This statement alo
Antonin Houska wrote:
> Jacob Champion wrote:
> > Now, the token introspection endpoint I mentioned upthread
>
> Can you please point me to the particular message?
Please ignore this dumb question. You probably referred to the email I was
responding to.
--
Antonin Houska
Web: https://www.cyb
Jacob Champion wrote:
> On Fri, Sep 27, 2024 at 10:58 AM Antonin Houska wrote:
> > Have you considered sending the token for validation to the server, like
> > this
> >
> > curl -X GET "https://www.googleapis.com/oauth2/v3/userinfo"; -H
> > "Authorization: Bearer $TOKEN"
>
> In short, no, but
On Fri, Sep 27, 2024 at 10:58 AM Antonin Houska wrote:
> Have you considered sending the token for validation to the server, like this
>
> curl -X GET "https://www.googleapis.com/oauth2/v3/userinfo"; -H
> "Authorization: Bearer $TOKEN"
In short, no, but I'm glad you asked. I think it's going to
Jacob Champion wrote:
> Peter asked me if there were plans to provide a "standard" validator
> module, say as part of contrib. The tricky thing is that Bearer
> validation is issuer-specific, and many providers give you an opaque
> token that you're not supposed to introspect at all.
>
> We coul
On Wed, Sep 11, 2024 at 3:54 PM Jacob Champion
wrote:
> Yeah, and I still owe you all an updated roadmap.
Okay, here goes. New reviewers: start here!
== What is This? ==
OAuth 2.0 is a way for a trusted third party (a "provider") to tell a
server whether a client on the other end of the line is
(Thanks for the commit, Peter!)
On Wed, Sep 11, 2024 at 6:44 AM Daniel Gustafsson wrote:
>
> > On 11 Sep 2024, at 09:37, Peter Eisentraut wrote:
>
> > Is there any sense in dealing with the libpq and backend patches separately
> > in sequence, or is this split just for ease of handling?
>
> I t
On 04.09.24 11:28, Peter Eisentraut wrote:
On 03.09.24 22:56, Jacob Champion wrote:
The parse_strval field could use a better explanation.
I actually don't understand the need for this field. AFAICT, this is
just used to record whether strval is valid.
No, it's meant to track the value of the
On 03.09.24 22:56, Jacob Champion wrote:
The parse_strval field could use a better explanation.
I actually don't understand the need for this field. AFAICT, this is
just used to record whether strval is valid.
No, it's meant to track the value of the need_escapes argument to the
constructor. I
On 28.08.24 18:31, Jacob Champion wrote:
On Mon, Aug 26, 2024 at 4:23 PM Jacob Champion
wrote:
I was having trouble reasoning about the palloc-that-isn't-palloc code
during the first few drafts, so I will try a round with the jsonapi_
prefix.
v27 takes a stab at that. I have kept the ALLOC/FR
On Mon, Aug 26, 2024 at 1:18 AM Peter Eisentraut wrote:
> Or, if people find that too scary, something like
>
> #ifdef JSONAPI_USE_PQEXPBUFFER
>
> #define jsonapi_StringInfo PQExpBuffer
> [...]
>
> That way, it's at least more easy to follow the source code because
> you see a mostly-familiar API.
On 13.08.24 23:11, Jacob Champion wrote:
On Sun, Aug 11, 2024 at 11:37 PM Peter Eisentraut wrote:
I have committed 0002 now.
Thanks Peter! Rebased over both in v26.
I have looked again at the jsonapi memory management patch (v26-0001).
As previously mentioned, I think adding a third or four
On 07.08.24 09:34, Peter Eisentraut wrote:
On 05.08.24 19:53, Jacob Champion wrote:
On Fri, Aug 2, 2024 at 11:48 AM Peter Eisentraut
wrote:
Yes, I think with an adjusted comment and commit message, the actual
change makes sense.
Done in v25.
...along with a bunch of other stuff:
I have co
On 05.08.24 19:53, Jacob Champion wrote:
On Fri, Aug 2, 2024 at 11:48 AM Peter Eisentraut wrote:
Yes, I think with an adjusted comment and commit message, the actual
change makes sense.
Done in v25.
...along with a bunch of other stuff:
I have committed 0001, and I plan to backpatch it onc
On 02.08.24 19:51, Jacob Champion wrote:
But it sounds like we agree that we shouldn't be using fe_memutils at
all in shlib builds. (If you can't use palloc -- it calls exit -- then
you can't use pfree either.) Is 0002 still worth pursuing, once I've
correctly wordsmithed the commit? Or did I mis
On Fri, Aug 2, 2024 at 10:13 AM Peter Eisentraut wrote:
> You shouldn't use pfree() interchangeably with free(), even if that is
> not enforced because it's the same thing underneath. First, it just
> makes sense to keep the alloc and free pairs matched up. And second, on
> Windows there is some
On 30.07.24 00:30, Jacob Champion wrote:
But under what circumstances does "the linker doesn't strip out" happen?
If this happens accidentally, then we should have seen some buildfarm
failures or something?
On my machine, for example, I see differences with optimization
levels. Say you inadve
On Mon, Jul 29, 2024 at 1:51 PM Daniel Gustafsson wrote:
> Together with a colleage we found the Azure provider use "verification_url"
> rather than xxx_uri.
Yeah, I think that's originally a Google-ism. (As far as I can tell
they helped author the spec for this and then didn't follow it. :/ ) I
On Mon, Jul 29, 2024 at 5:02 AM Peter Eisentraut wrote:
> We should take the check for exit() calls from libpq and expand it to
> cover the other libraries as well. Maybe there are other problems like
> this?
Seems reasonable, yeah.
> But under what circumstances does "the linker doesn't strip
Thanks for working on this patchset, I'm looking over 0004 and 0005 but came
across a thing I wanted to bring up one thing sooner than waiting for the
review. In parse_device_authz we have this:
{"user_code", JSON_TOKEN_STRING, {&authz->user_code}, REQUIRED},
{"verification_uri", JSON_TOKEN_ST
I have some comments about the first three patches, that deal with
memory management.
v24-0001-Revert-ECPG-s-use-of-pnstrdup.patch
This looks right.
I suppose another approach would be to put a full replacement for
strndup() into src/port/. But since there is currently only one user,
and mo
On Thu, Mar 28, 2024 at 3:34 PM Daniel Gustafsson wrote:
> In jsonapi.c, makeJsonLexContextCstringLen initialize a JsonLexContext with
> palloc0 which would need to be ported over to use ALLOC for frontend code.
Seems reasonable (but see below, too).
> On
> that note, the errorhandling in parse_
On Thu, Feb 29, 2024 at 1:08 PM Daniel Gustafsson wrote:
> + /* TODO */
> + CHECK_SETOPT(actx, CURLOPT_WRITEDATA, stderr);
> I might be missing something, but what this is intended for in
> setup_curl_handles()?
Ah, that's cruft left over from early debugging, just so that I could
see what wa
On Wed, Feb 28, 2024 at 9:40 AM Daniel Gustafsson wrote:
> +#define ALLOC(size) malloc(size)
> I wonder if we should use pg_malloc_extended(size, MCXT_ALLOC_NO_OOM) instead
> to self document the code. We clearly don't want feature-parity with server-
> side palloc here. I know we use malloc in
> On 27 Feb 2024, at 20:20, Jacob Champion
> wrote:
>
> On Fri, Feb 23, 2024 at 5:01 PM Jacob Champion
> wrote:
>> The
>> patchset is now carrying a lot of squash-cruft, and I plan to flatten
>> it in the next version.
>
> This is done in v17, which is also now based on the two patches pulled
[re-adding the CC list I dropped earlier]
On Wed, Feb 28, 2024 at 1:52 PM Daniel Gustafsson wrote:
>
> > On 28 Feb 2024, at 22:50, Andrew Dunstan wrote:
> > Can you give some more details about what this python gadget would buy us?
> > I note that there are a couple of CPAN modules that provide
> On 28 Feb 2024, at 22:50, Andrew Dunstan wrote:
>
> On 2024-02-28 We 09:05, Jacob Champion wrote:
>>
>> Daniel and I discussed trying a Python version of the test server,
>> since the standard library there should give us more goodies to work
>> with. A proof of concept is in 0009. I think the
On 2024-02-28 We 09:05, Jacob Champion wrote:
Daniel and I discussed trying a Python version of the test server,
since the standard library there should give us more goodies to work
with. A proof of concept is in 0009. I think the big question I have
for it is, how would we communicate what we
> On 28 Feb 2024, at 15:05, Jacob Champion
> wrote:
>
> [Trying again, with all patches unzipped and the CC list temporarily
> removed to avoid flooding people's inboxes. Original message follows.]
>
> On Fri, Feb 23, 2024 at 5:01 PM Jacob Champion
> wrote:
>> The
>> patchset is now carrying a
On Tue, Feb 27, 2024 at 11:20 AM Jacob Champion
wrote:
> This is done in v17, which is also now based on the two patches pulled
> out by Daniel in [1].
It looks like my patchset has been eaten by a malware scanner:
550 Message content failed content scanning
(Sanesecurity.Foxhole.Mail_gz.UNO
Hi all,
v14 rebases over latest and fixes a warning when assertions are
disabled. 0006 is temporary and hacks past a couple of issues I have
not yet root caused -- one of which makes me wonder if 0001 needs to
be considered alongside the recent pg_combinebackup and incremental
JSON work...?
--Jac
On Tue, Dec 5, 2023 at 1:44 AM Daniel Gustafsson wrote:
>
> > On 8 Nov 2023, at 20:00, Jacob Champion wrote:
>
> > Unfortunately the configure/Makefile build of libpq now seems to be
> > pulling in an `exit()` dependency in a way that Meson does not.
>
> I believe this comes from the libcurl and
> On 8 Nov 2023, at 20:00, Jacob Champion wrote:
> Unfortunately the configure/Makefile build of libpq now seems to be
> pulling in an `exit()` dependency in a way that Meson does not.
I believe this comes from the libcurl and specifically the ntlm_wb support
which is often enabled in system and
On Thu, Nov 9, 2023 at 5:43 PM Andrey Chudnovsky wrote:
> Do you plan to support adding an extension hook to validate the token?
>
> It would allow a more efficient integration, then spinning a separate process.
I think an API in the style of archive modules might probably be a
good way to go, ye
Hi Jacob,
Wanted to follow up on one of the topics discussed here in the past:
Do you plan to support adding an extension hook to validate the token?
It would allow a more efficient integration, then spinning a separate
process.
Thanks!
Andrey.
On Wed, Nov 8, 2023 at 11:00 AM Jacob Champion wr
On Fri, Nov 3, 2023 at 5:28 AM Shlok Kyal wrote:
> Just want to make sure you are aware of these failures.
Thanks for the nudge! Looks like I need to reconcile with the changes
to JsonLexContext in 1c99cde2. I should be able to get to that next
week; in the meantime I'll mark it Waiting on Author
Hi,
On Fri, 3 Nov 2023 at 17:14, Jacob Champion wrote:
>
> v12 implements a first draft of a client hook, so applications can
> replace either the device prompt or the entire OAuth flow. (Andrey and
> Mahendrakar: hopefully this is close to what you need.) It also cleans
> up some of the JSON tec
v11 is a quick rebase over the recent Cirrus changes, and I've dropped
0006 now that psycopg2 can build against BSD/Meson setups (thanks Daniele!).
--Jacob1: 0278c7ba90 = 1: 36409a76ce common/jsonapi: support FRONTEND clients
2: bb3ce4b6a9 = 2: 1356b729db libpq: add OAUTHBEARER SASL mechanism
On Tue, Jul 18, 2023 at 4:04 PM Thomas Munro wrote:
> On Tue, Jul 18, 2023 at 11:55 AM Jacob Champion
> wrote:
> +1 for EV_RECEIPT ("just tell me about errors, don't drain any
> events").
Sounds good.
> While comparing the cousin OSs' man pages just now, I noticed that
> it's not only macOS th
On Tue, Jul 18, 2023 at 11:55 AM Jacob Champion wrote:
> We're not setting EV_RECEIPT for these -- is that because none of the
> filters we're using are EV_CLEAR, and so it doesn't matter if we
> accidentally pull pending events off the queue during the kevent() call?
+1 for EV_RECEIPT ("just tel
> > - Parameters are strings, so callback is not provided yet.
> > 2. Client gets PgConn from PQconnectStart return value and updates
> > conn->async_auth to its own callback.
>
> This is where some sort of official authn callback registration (see
> above reply to Daniele) would probably come in
On Wed, Jul 12, 2023 at 5:50 AM Jacob Champion wrote:
> Oh, whoops, it's just the missed CLOEXEC flag in the final patch. (If
> the write side of the pipe gets copied around, it hangs open and the
> validator never sees the "end" of the token.) I'll switch the logic
> around to set the flag on the
On Mon, Jul 10, 2023 at 4:50 PM Jacob Champion wrote:
> I don't understand why the
> server-side tests are failing on FreeBSD, but they shouldn't be using
> the libpq code at all, so I think your kqueue implementation is in the
> clear.
Oh, whoops, it's just the missed CLOEXEC flag in the final p
On Fri, Jul 7, 2023 at 6:01 PM Thomas Munro wrote:
>
> On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> > On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> > > BTW I will happily do the epoll->kqueue port work if necessary.
> >
> > And I will happily take you up on that; thanks!
>
> Som
On Fri, Jul 7, 2023 at 2:16 PM Andrey Chudnovsky wrote:
> Please confirm my understanding of the flow is correct:
> 1. Client calls PQconnectStart.
> - The client doesn't know yet what is the issuer and the scope.
Right. (Strictly speaking it doesn't even know that OAuth will be used
for the co
On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> > BTW I will happily do the epoll->kqueue port work if necessary.
>
> And I will happily take you up on that; thanks!
Some initial hacking, about 2 coffees' worth:
https://github.com/macdi
Thanks Jacob for making progress on this.
> 3) Is the current conn->async_auth() entry point sufficient for an
> application to implement the Microsoft flows discussed upthread?
Please confirm my understanding of the flow is correct:
1. Client calls PQconnectStart.
- The client doesn't know yet
On Thu, Jul 6, 2023 at 1:48 PM Thomas Munro wrote:
> On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> > Something analogous to libcurl's socket and timeout callbacks [1],
> > then? Or is there an existing libpq API you were thinking about using?
>
> Yeah. Libpq already has an event concept
On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> > 2. Convert those events into new libpq events like 'I want you to
> > call me back in 100ms', and 'call me back when socket #42 has data',
> > and let clients handle that by managing the
On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> I guess there are a couple of ways to do it if we give up the goal of
> no-code-change-for-the-client:
>
> 1. Generalised PQsocket(), that so that a client can call something like:
>
> int PQpollset(const PGConn *conn, struct pollfd fds[], int
1 - 100 of 157 matches
Mail list logo
