Re: [PoC] Federated Authn/z with OAUTHBEARER
Peter Eisentraut <peter@eisentraut.org>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
meson: Fix install-quiet after clean
- a9ffb35274fb 18.0 landed
- 4ae03be54734 19 (unreleased) landed
-
oauth: Run Autoconf tests with correct compiler flags
- 3d23f68c5529 18.0 landed
- 990571a08b66 19 (unreleased) landed
-
Link libpq with libdl if the platform needs that.
- 4df477153a6b 19 (unreleased) landed
- 7bd752c1fb8e 18.0 landed
-
Doc: correct spelling of meson switch.
- 3faac9d14063 16.9 landed
- 766d2e673342 17.5 landed
- ac557793d478 18.0 landed
-
oauth: Correct SSL dependency for libpq-oauth.a
- 3db68212a393 18.0 landed
-
oauth: Fix Autoconf build on macOS
- 4ea1254f35b2 18.0 cited
-
oauth: Move the builtin flow into a separate module
- b0635bfda053 18.0 landed
-
Remove a stray "pgrminclude" annotation
- 764d501d24ba 18.0 cited
-
oauth: Simplify copy of PGoauthBearerRequest
- 1cf4c56480f8 18.0 landed
-
oauth: Improve validator docs on interruptibility
- 873c0fd67872 18.0 landed
-
oauth: Disallow synchronous DNS in libcurl
- d7e40845f923 18.0 landed
-
oauth: Fix postcondition for set_timer on macOS
- 434dbf6907ec 18.0 landed
-
oauth: Use IPv4-only issuer in oauth_validator tests
- 8d9d5843b55f 18.0 landed
-
Work around OAuth/EVFILT_TIMER quirk on NetBSD.
- c301a0a74a8a 18.0 landed
-
oauth: Fix incorrect const markers in struct
- 03366b61dfe5 18.0 landed
-
Add missing entry to oauth_validator test .gitignore
- 2c53dec7f440 18.0 landed
-
cirrus: Temporarily fix libcurl link error
- 9d9a71002a1c 18.0 landed
-
Add support for OAUTHBEARER SASL mechanism
- b3f0be788afc 18.0 landed
-
libpq: Handle asynchronous actions during SASL
- a99a32e43ed7 18.0 landed
-
require_auth: prepare for multiple SASL mechanisms
- f8d8581ed882 18.0 landed
-
Move PG_MAX_AUTH_TOKEN_LENGTH to libpq/auth.h
- e21d6f297158 18.0 landed
-
Make SASL max message length configurable
- 6d16f9debae0 18.0 landed
-
jsonapi: fully initialize dummy lexer
- 41b023946dfd 18.0 landed
-
common/jsonapi: support libpq as a client
- 0785d1b8b2fa 18.0 landed
-
Remove fe_memutils from libpgcommon_shlib
- f1976df5eaf2 18.0 landed
-
Revert ECPG's use of pnstrdup()
- f0096ef13be2 13.17 landed
- 3557185538fe 14.14 landed
- 2de129b356bf 15.9 landed
- ee2997c678d8 16.5 landed
- e9e05c655069 17.0 landed
- 5388216f6adc 18.0 landed
-
Explicitly require password for SCRAM exchange
- adcdb2c8dda4 17.0 landed
-
Refactor SASL exchange to return tri-state status
- 24178e235ea5 17.0 landed
On 07.04.25 16:43, Andres Freund wrote: >>> While I was looking into this I found that Debian's going to use the >>> existence of an SONAME to check other things, which I assume will make >>> Christoph's life harder. I have switched over to >>> 'libpq-oauth-<major>.so', without any SONAME or symlinks. >> Yes, this is correct. We want a shared module, not a shared library, in >> meson parlance. > It's not entirely obvious to me that we do want that. > > There recently was a breakage of building with PG on macos with meson, due to > the meson folks implementing a feature request to move away from using > bundles, as > 1) bundles apparently aren't supported on iOS > 2) there apparently aren't any restrictions left that require using bundles, > and there haven't been for a while. > > They've now reverted these changes, due to the postgres build failures that > caused as well as recognizing they probably moved too fast, but the iOS > portion seems like it could be relevant for us? Um, interesting. AFAICT, the change you mention was reverted from the 1.7 branch because it was accidentally backpatched, but it remains in master. (For those just catching up: https://github.com/mesonbuild/meson/issues/14240 https://github.com/mesonbuild/meson/pull/14340 https://github.com/mesonbuild/meson/commit/fa3f7e10b47d1f2f438f216f6c44f56076a01bfc ) Overall, this seems like a good idea, as it removes a historical platform-specific particularity. (I found a historical analysis at <https://stackoverflow.com/questions/2339679/>.) But it does break existing users that add -bundle_loader, because -bundle_loader only works with -bundle and is rejected with -dynamiclib. To test, I patched the makefiles to use -dynamiclib instead of -bundle, which also required removing -bundle_loader, and it also required adding -Wl,-undefined,dynamic_lookup. This built correctly and generally worked. But then you also run into a new variant of this issue: https://www.postgresql.org/message-id/E1o4HOv-001Oyi-5n@gemulon.postgresql.org Because there is no -bundle_loader, the symbol search order appears to be different, and so hash_search() gets found in the OS library first. So this is all going to be a mess at some point sooner or later. :-( > Afaict this library doesn't have unresolved symbols, due to just linking to > libpq. So I don't think we really need this to be a shared module? Apart from the hard distinction on macOS, in terms of the build system, the distinction between "library" and "module" is mainly whether the resulting library gets a soname, version symlinks, and what directory it is installed in, so in that sense the discussion so far indicates that it should be a module. I suppose on macOS we could link it like a library and install it like a module, but that would effectively create a third category, and I don't see why that would be worth it.