Re: [PoC] Federated Authn/z with OAUTHBEARER

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.