Message-ID: <fca05269-ea5e-6eff-a664-75795c12bf5c@timescale.com>
Date: Thu, 29 Jun 2023 09:28:24 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
From: Jacob Champion <jchampion@timescale.com>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Cc: "hlinnaka@iki.fi" <hlinnaka@iki.fi>,
 "michael@paquier.xyz" <michael@paquier.xyz>,
 "smilingsamay@gmail.com" <smilingsamay@gmail.com>,
 Stephen Frost <sfrost@snowman.net>,
 mahendrakar s <mahendrakarforpg@gmail.com>,
 Andrey Chudnovsky <achudnovskij@gmail.com>
References: <d1b467a78e0e36ed85a09adf979d04cf124a9d4b.camel@vmware.com>
 <e866a4a3-0ba6-c7ae-3abc-aaff0c033558@iki.fi>
 <2f06a4aef1d5defe4b7aaec01478572e5557d32a.camel@vmware.com>
 <8a5a35b31c3f25f6b047e77def0445a60399981d.camel@vmware.com>
 <0e86fe7e3534fb05db02379fed404a2010eb1d62.camel@vmware.com>
 <4db7d3ea061f47a15fc6d865f53dd327ea2975fb.camel@vmware.com>
 <CAAWbhmiWudPQk2euOQQPPa=o14zCN9U_qLwU1pShKO4A-F9yeA@mail.gmail.com>
 <CAAWbhmgWHhqVUkd0nRh59OpVpy_ewfUimqx+NMaWwGNqk=660g@mail.gmail.com>
 <863c9732-524e-af8f-0c79-700e2c171fa7@timescale.com>
Content-Language: en-US
In-Reply-To: <863c9732-524e-af8f-0c79-700e2c171fa7@timescale.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/fca05269-ea5e-6eff-a664-75795c12bf5c%40timescale.com>
Precedence: bulk


On 5/19/23 15:01, Jacob Champion wrote:
> But I don't want to
> gold-plate it if this overall approach is unacceptable. So, questions
> for the gallery:
> 
> 1) Would starting up a background thread (pooled or not) be acceptable
> on Windows? Alternatively, does anyone know enough Winsock deep magic to
> combine multiple pending events into one (selectable!) socket?
> 
> 2) If a background thread is acceptable on one platform, does it make
> more sense to use one on every platform and just have synchronous code
> everywhere? Or should we use a threadless async implementation when we can?
> 
> 3) Is the current conn->async_auth() entry point sufficient for an
> application to implement the Microsoft flows discussed upthread?
> 
> 4) Would we want to try to require a new enough cURL/OpenSSL to avoid
> thread safety problems during initialization, or do we need to introduce
> some API equivalent to PQinitOpenSSL?
> 
> 5) Does this maintenance tradeoff (full control over the client vs. a
> large amount of RFC-governed code) seem like it could be okay?

There was additional interest at PGCon, so I've registered this in the
commitfest.

Potential reviewers should be aware that the current implementation
requires Linux (or, more specifically, epoll), as the cfbot shows. But
if you have any opinions on the above questions, those will help me
tackle the other platforms. :D

Thanks!
--Jacob