Re: [PoC] Federated Authn/z with OAUTHBEARER

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>
To: Andres Freund <andres@anarazel.de>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, Christoph Berg <myon@debian.org>, Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Daniel Gustafsson <daniel@yesql.se>, Thomas Munro <thomas.munro@gmail.com>, Nazir Bilal Yavuz <byavuz81@gmail.com>, Antonin Houska <ah@cybertec.at>
Date: 2025-04-07T16:38:19Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. meson: Fix install-quiet after clean

  2. oauth: Run Autoconf tests with correct compiler flags

  3. Link libpq with libdl if the platform needs that.

  4. Doc: correct spelling of meson switch.

  5. oauth: Correct SSL dependency for libpq-oauth.a

  6. oauth: Fix Autoconf build on macOS

  7. oauth: Move the builtin flow into a separate module

  8. Remove a stray "pgrminclude" annotation

  9. oauth: Simplify copy of PGoauthBearerRequest

  10. oauth: Improve validator docs on interruptibility

  11. oauth: Disallow synchronous DNS in libcurl

  12. oauth: Fix postcondition for set_timer on macOS

  13. oauth: Use IPv4-only issuer in oauth_validator tests

  14. Work around OAuth/EVFILT_TIMER quirk on NetBSD.

  15. oauth: Fix incorrect const markers in struct

  16. Add missing entry to oauth_validator test .gitignore

  17. cirrus: Temporarily fix libcurl link error

  18. Add support for OAUTHBEARER SASL mechanism

  19. libpq: Handle asynchronous actions during SASL

  20. require_auth: prepare for multiple SASL mechanisms

  21. Move PG_MAX_AUTH_TOKEN_LENGTH to libpq/auth.h

  22. Make SASL max message length configurable

  23. jsonapi: fully initialize dummy lexer

  24. common/jsonapi: support libpq as a client

  25. Remove fe_memutils from libpgcommon_shlib

  26. Revert ECPG's use of pnstrdup()

  27. Explicitly require password for SCRAM exchange

  28. Refactor SASL exchange to return tri-state status

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.