Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 8 Apr 2025 12:34:02 +0200

> On 8 Apr 2025, at 04:10, Jacob Champion <[email-masked]> wrote:
> 
> On Mon, Apr 7, 2025 at 3:26 PM Jacob Champion
> <[email-masked]> wrote:
>> Sounds good. Any opinions from the gallery on what a "libpq plugin
>> subdirectory" in pkglibdir should be called? ("client", "modules",
>> "plugins"...?)
> 
> Hm, one immediate consequence of hardcoding pkglibdir is that we can
> no longer rely on LD_LIBRARY_PATH for pre-installation testing.
> (Contrast with the server, which is able to relocate extension paths
> based on its executable location.)

That strikes me as a signifant drawback.

--
Daniel Gustafsson

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 8 Apr 2025 10:32:21 -0400

> That strikes me as a signifant drawback.

Uh, where are we on the inclusion of curl in our build?  Maybe it was
explained but I have not seen it.  I still see
src/interfaces/libpq/fe-auth-oauth-curl.c.

-- 
  Bruce Momjian  <[email-masked]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

---

From: Jacob Champion <[email-masked]>
Date: Tue, 8 Apr 2025 08:04:22 -0700

On Tue, Apr 8, 2025 at 7:32 AM Bruce Momjian <[email-masked]> wrote:
> explained but I have not seen it.

The above is discussing a patch to split this into its own loadable
module. Andres and Christoph's feedback has been shaping where we put
that module, exactly.

Thanks,
--Jacob

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 8 Apr 2025 11:13:51 -0400

> module. Andres and Christoph's feedback has been shaping where we put

Uh, I was afraid that was the case, which is why I asked.  We have just
hit feature freeze, so it is not good that we are still "shaping" the
patch.  Should we consider reverting it?  It is true we still "adjust"
patches after feature freeze.

---

From: Andres Freund <[email-masked]>
Date: Tue, 8 Apr 2025 11:20:11 -0400

Hi,

> patches after feature freeze.

You brought the dependency concern up well after the feature was merged, after
it had been in development for a *long* time. It wasn't a secret that it had a
dependency on curl.  I don't think it's fair to penalize a feature's authors
to not finish implementing a complicated and completely new requirement within
17 days.

Greetings,

Andres Freund

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 8 Apr 2025 11:22:21 -0400

> to not finish implementing a complicated and completely new requirement within

Fair point --- I was just asking.

---

From: Jacob Champion <[email-masked]>
Date: Tue, 8 Apr 2025 10:36:08 -0700

> That strikes me as a signifant drawback.

Yeah, but it's one of those things that feels like it must have been
solved by the others in the space. Once it's installed, the concern
goes away (unless you demand absolute relocatability without
recompilation). I'll take a look at how libkrb/libmagick do their
testing.

If it somehow turns out to be impossible, one option might be to shove
a more detailed ABI identifier into the name. In other words, builds
without ENABLE_SSL/GSS/SSPI or whatever get different names on disk.
That doesn't scale at all, but it's a short-term option that would put
more pressure on a medium-term stable ABI.

Thanks,
--Jacob

---

From: Jacob Champion <[email-masked]>
Date: Tue, 8 Apr 2025 12:07:51 -0700

> recompilation). I'll take a look at how libkrb/libmagick do their

Perhaps unsurprisingly, they inject different lookup paths via
envvars. We could do the same (I have FUD about the security
characteristics)...

> a more detailed ABI identifier into the name.

...but I wonder if I can invert the dependency on
libpq_append_conn_error entirely, and remove that part of the ABI
surface, then revisit the discussion on `-<major>.so` vs
`-<major>-<minor>.so`.

--Jacob