Re: [PoC] Federated Authn/z with OAUTHBEARER

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter@eisentraut.org>
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:52:57Z
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

Hi,

On 2025-04-07 18:38:19 +0200, Peter Eisentraut wrote:
> On 07.04.25 16:43, Andres Freund wrote:
> > 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.

I think the plan is to either redesign it in master or to revert it.


> (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.

Seems hard to imagine that somebody would inject -bundle_loader separately
from src/makefiles/Makefile.darwin?


> 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. :-(

Yikes, that is depressing / scary.  I wonder if we ought to rename our
hash_search with some macro magic or such regardless of using -bundle or not.


> > 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 don't think that happens if you don't specify a soname etc. And we'd need to
adjust the install dir either way, I think?


> 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.

I think there are postgres clients for iphone, not sure if they use
libpq. Today libpq might actually cross-build successfully for iOS [1]. But if
we use shared_module() that won't be the case for libpq-oauth.

Anyway, I don't have a strong position on this, I just wanted to bring it up
for consideration.

Greetings,

Andres Freund

[1] I couldn't immediately quickly figure out how to install additional SDKs
on the commandline on macos an then gave up before attaching a monitor to my
mac mini.