public inbox for [email protected]
help / color / mirror / Atom feedFrom: Daniel Gustafsson <[email protected]>
To: Jacob Champion <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Nazir Bilal Yavuz <[email protected]>
Cc: Antonin Houska <[email protected]>
Cc: Wolfgang Walther <[email protected]>
Cc: Devrim Gündüz <[email protected]>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Date: Wed, 30 Apr 2025 14:55:07 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAOYmi+=UsSnLM4K+hYkhrezpQROQ5jr=72feAkQ0Te8GJf3Fbg@mail.gmail.com>
References: <[email protected]>
<CAOYmi+n9DHS_xUatuuspdC8tjtaMzY8P11Y9y5Fz+2pjikkL9g@mail.gmail.com>
<[email protected]>
<CAOYmi+=2cArQoSSRdAYwx2TBSHL5r0UhX28Q-5TP=0g-sxBXCA@mail.gmail.com>
<CAGECzQShbNtypPqabVv2eKJP=0Ejox=6f8k8G1E-2GN6Ag1kAA@mail.gmail.com>
<CAOYmi+=j9nLQFjQ8z0vyQmuhNMwsFbzvne_2S2pTbBGir4q6EQ@mail.gmail.com>
<[email protected]>
<CAOYmi+k9uN2OQ_sXjztZYPSpPbfGmkkv4yhtPhyjNQ6vy7SSfA@mail.gmail.com>
<[email protected]>
<CAOYmi+=WA4ZfyHWt+4=yFV7VAXQWvNKsn4R=3PwLd4GfmSTiBA@mail.gmail.com>
<[email protected]>
<CAOYmi+=cs+gDTAH0L+3JzpRLeHPOXDQxu7MOfsbjah9SkAP_kw@mail.gmail.com>
<CAOYmi+=UsSnLM4K+hYkhrezpQROQ5jr=72feAkQ0Te8GJf3Fbg@mail.gmail.com>
> On 29 Apr 2025, at 02:10, Jacob Champion <[email protected]> wrote:
>
> On Wed, Apr 23, 2025 at 10:46 AM Jacob Champion
> <[email protected]> wrote:
>> Are there any readers who feel like an internal ABI version for
>> `struct pg_conn`, bumped during breaking backports, would be
>> acceptable? (More definitively: are there any readers who would veto
>> that?)
>
> To keep things moving: I assume this is unacceptable. So v10 redirects
> every access to a PGconn struct member through a shim, similarly to
> how conn->errorMessage was translated in v9. This adds plenty of new
> boilerplate, but not a whole lot of complexity. To try to keep us
> honest, libpq-int.h has been removed from the libpq-oauth includes.
That admittedly seems like a win regardless.
> This will now handle in-place minor version upgrades that swap pg_conn
> internals around, so I've gone back to -MAJOR versioning alone.
> fe_oauth_state is still exported; it now has an ABI warning above it.
> (I figure that's easier to draw a line around during backports,
> compared to everything in PGconn. We can still break things there
> during major version upgrades.)
While I'm far from the expert on this subject (luckily there are such in this
thread), I am unable to see any sharp edges from reading and testing this
version of the patch. A few small comments:
+libpq-oauth is an optional module implementing the Device Authorization flow for
+OAuth clients (RFC 8628). It was originally developed as part of libpq core and
+later split out as its own shared library in order to isolate its dependency on
+libcurl. (End users who don't want the Curl dependency can simply choose not to
+install this module.)
We should either clarify that it was never shipped as part of libpq core, or
remove this altogether. I would vote for the latter since we typically don't
document changes that happen during the devcycle. How about something like:
+libpq-oauth is an optional module implementing the Device Authorization flow for
+OAuth clients (RFC 8628). It is maintained as its own shared library in order to
+isolate its dependency on libcurl. (End users who don't want the Curl dependency
+can simply choose not to install this module.)
+- void libpq_oauth_init(pgthreadlock_t threadlock,
+ <snip>
+At the moment, pg_fe_run_oauth_flow() relies on libpq's pg_g_threadlock and
+libpq_gettext(), which must be injected by libpq using this initialization
+function before the flow is run.
I think this explanatory paragraph should come before the function prototype.
The following paragraph on the setters/getters make sense where it is though.
+#if defined(USE_DYNAMIC_OAUTH) && defined(LIBPQ_INT_H)
+#error do not rely on libpq-int.h in libpq-oauth.so
+#endif
Nitpick, but it won't be .so everywhere. Would this be clearar if spelled out
with something like "do not rely on libpq-int.h when building libpq-oauth as
dynamic shared lib"?
--
Daniel Gustafsson
view thread (31+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox