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

From: Wolfgang Walther <[email-masked]>
Date: Tue, 8 Apr 2025 18:01:42 +0200

Jacob Champion:
> The above is discussing a patch to split this into its own loadable
> module.

Wasn't sure where to put this exactly, the thread is long and I couldn't 
find any discussion around it:

How does the proposal with a loadable module affect a static libpq.a?

I have not tried, yet, but is my assumption correct, that I could build 
a libpq.a with oauth/curl support on current HEAD?

If yes, would that still be an option after the split?

Thanks,

Wolfgang

---

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

On Tue, Apr  8, 2025 at 06:01:42PM +0200, Wolfgang Walther wrote:
> I have not tried, yet, but is my assumption correct, that I could build a
> libpq.a with oauth/curl support on current HEAD?
> 

How does this patch help us avoid having to handle curl CVEs and its
curl's additional dependencies?  As I understand the patch, it makes
libpq _not_ have additional dependencies but moves the dependencies to a
special loadable library that libpq can use.

-- 
  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 09:14:54 -0700

> How does the proposal with a loadable module affect a static libpq.a?

The currently proposed patch would have you package and install a
separate .so module implementing OAuth, which the staticlib would load
once when needed. Similarly to how you still have to somehow
dynamically link your static app against Curl.

As a staticlib user, how do you feel about that?

> a libpq.a with oauth/curl support on current HEAD?

Yes.

--Jacob

---

From: Jacob Champion <[email-masked]>
Date: Tue, 8 Apr 2025 09:17:03 -0700

> special loadable library that libpq can use.

It allows packagers to ship the OAuth library separately, so end users
that don't want the additional exposure don't have to install it at
all.

--Jacob

---

From: Wolfgang Walther <[email-masked]>
Date: Tue, 8 Apr 2025 18:32:35 +0200

> As a staticlib user, how do you feel about that?

When linking statically, I am producing entirely statically linked 
single binaries. Those contain libpq, all other dependencies, and would 
also contain curl.

The "entirely statically linked" thing is actually enforced by the build 
system (NixOS' pkgsStatic here), so dlopen() might just not be possible. 
Not exactly sure right now, whether it's stubbed out or just not 
available at all.

This means that shipping another .so file will not happen with this 
approach. Assuming OAuth will be picked up by some of the bigger 
providers, that would... make me feel quite bad about it, actually.

I'm not seeing the overall problem, yet. When I build with 
--enable-curl... ofc, I have a dependency on cURL. That's kind of the 
point. When I don't want that, then I just disable it. And that should 
also not be a problem for distributions - they could offer a libpq and a 
libpq_oauth package, where only one of them can be installed at the same 
time, I guess? *

Best,

Wolfgang

* Currently, the two build systems don't handle the "please build only 
libpq" scenario well. If that was supported better, building a second 
package with oauth support could be much easier.

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 8 Apr 2025 12:33:55 -0400

> that don't want the additional exposure don't have to install it at

Okay, so how would they do that?  I understand how that would happen if
it was an external extension, but how if it is under /src or /contrib.

FYI, I see a good number of curl CVEs:

	https://curl.se/docs/security.html

Would we have to put out minor releases for curl CVEs?  I don't think we
have to for OpenSSL so would curl be the same?

I am asking these questions now so we can save time in getting this
closed.

---

From: Wolfgang Walther <[email-masked]>
Date: Tue, 8 Apr 2025 18:35:05 +0200

Ah, this came in after I sent my other mail, with this foot-note:

 > Currently, the two build systems don't handle the "please build only 

I think we should rather improve the build systems to handle this case, 
to give packagers more flexibility.

Best,

Wolfgang

---

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 8 Apr 2025 18:42:19 +0200

> On 8 Apr 2025, at 18:33, Bruce Momjian <[email-masked]> wrote:

> have to for OpenSSL so would curl be the same?

Why do you envision this being different from all other dependencies we have?
For OpenSSL we also happily build against a version (and until recently,
several versions) which is EOL and don't even recieve security fixes.

--
Daniel Gustafsson

---

From: Jacob Champion <[email-masked]>
Date: Tue, 8 Apr 2025 09:43:01 -0700

> it was an external extension, but how if it is under /src or /contrib.

By adding the new .so to a different package. For example, RPM specs
would just let you say "hey, this .so I just built doesn't go into the
main client package, it goes into an add-on that depends on the client
package." It's the same way separate client and server packages get
generated from the same single build of Postgres.

> Would we have to put out minor releases for curl CVEs?

In general, no.

Thanks,
--Jacob

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 8 Apr 2025 12:48:15 -0400

On Tue, Apr  8, 2025 at 06:42:19PM +0200, Daniel Gustafsson wrote:
> several versions) which is EOL and don't even receive security fixes.

I don't know.  I know people scan our downloads and report when the
scanners detect something, but I am unclear what those scanners are
doing.  Would they see some new risks with curl?

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 8 Apr 2025 12:49:58 -0400

> generated from the same single build of Postgres.

Do we have any idea how many packagers are interested in doing this?

> > Would we have to put out minor releases for curl CVEs?

Good.

FYI, I saw bug bounty dollar amounts next to each curl CVE:

No wonder some people ask for bounties.

---

From: Jacob Champion <[email-masked]>
Date: Tue, 8 Apr 2025 09:50:26 -0700

On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther <[email-masked]> wrote:
> And that should also not be a problem for distributions - they could offer a libpq and a libpq_oauth package, where only one of them can be installed at the same time, I guess? *

My outsider understanding is that maintaining this sort of thing
becomes a major headache, because of combinatorics. You don't really
want to ship a libpq and libpq-with-gss and libpq-with-oauth and
libpq-with-oauth-and-gss and ...

--Jacob

---

From: Wolfgang Walther <[email-masked]>
Date: Tue, 8 Apr 2025 18:57:18 +0200

> libpq-with-oauth-and-gss and ...

That would only be the case, if you were to consider those other 
dependencies as "dangerous" as cURL. But we already depend on them. So 
if it's really the case that cURL is that much worse, that we consider 
loading it as a module... then the combinatorics should not be a problem 
either.

However, if the other deps are considered problematic as well, then the 
ship has already sailed, and there is not point for a special case here 
anymore.

Best,

Wolfgang

---

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

> Do we have any idea how many packagers are interested in doing this?

I'm not sure how to answer this. The primary drivers from the dev side
are you and Tom, I think. Christoph seems to be on board with a split
as long as we don't make his life harder. Wolfgang appears to be a
packager who would not make use of a split (and in fact cannot).

--Jacob

---

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

On Tue, Apr  8, 2025 at 06:57:18PM +0200, Wolfgang Walther wrote:
> dependencies as "dangerous" as cURL. But we already depend on them. So if
> it's really the case that cURL is that much worse, that we consider loading
> it as a module... then the combinatorics should not be a problem either.
> 
> However, if the other deps are considered problematic as well, then the ship
> has already sailed, and there is not point for a special case here anymore.

Yes, I think this is what I am asking too.  For me it was curl's
security reputation and whether that would taint the security reputation
of libpq. For Tom, I think it was the dependency additions.

---

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

> packager who would not make use of a split (and in fact cannot).

Okay, I have just posted a more detailed email about my security
concern, so let's look at that.  I am ready to admit I am wrong.

---

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

On Tue, Apr 8, 2025 at 9:57 AM Wolfgang Walther <[email-masked]> wrote:
> if it's really the case that cURL is that much worse

(it is not, but I am sympathetic to the argument that if you don't use
it, you don't need it in the process space)

> ship has already sailed, and there is not point for a special case here

I think this line of argument is unlikely to find traction. Upthread
there were people asking if we could maybe split out other
possibly-unused dependencies in the future, like Kerberos.

--Jacob

---

From: Wolfgang Walther <[email-masked]>
Date: Tue, 8 Apr 2025 19:10:07 +0200

> possibly-unused dependencies in the future, like Kerberos.

Well, yes, that's kind of what I'm saying. There shouldn't be a special 
case for cURL, but those other deps should be handled equally as well.

And if that means making libpq modular at run-time, then this should be 
planned and built with all deps, and other use-cases (like static 
linking) in mind - and not like it is right now.

Best,

Wolfgang

---

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

On Tue, Apr 8, 2025 at 10:10 AM Wolfgang Walther
<[email-masked]> wrote:
> And if that means making libpq modular at run-time, then this should be planned and built with all deps, and other use-cases (like static linking) in mind - and not like it is right now.

I think that'd be neat in concept, but specifically this thread is
discussing a PG18 open item. For future releases, if we're happy with
how Curl gets split out, maybe that would be fuel for other
delay-loaded client dependencies. I'm not sure.

--Jacob

---

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

> delay-loaded client dependencies. I'm not sure.

Well, if we think we are going to do that, it seems we would need a
different architecture than the one being proposed for PG 18, which
could lead to a lot of user/developer API churn.

---

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

> could lead to a lot of user/developer API churn.

A major goal of the current patch proposal is to explicitly hide this
from the end-user and public APIs. So it can be changed without public
breakage. It can't be hidden from packagers, of course, but that's the
point of the feature request.

--Jacob

---

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

On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther <[email-masked]> wrote:
> This means that shipping another .so file will not happen with this approach. Assuming OAuth will be picked up by some of the bigger providers, that would... make me feel quite bad about it, actually.

It occurs to me that I didn't respond to this point explicitly. I
would like to avoid making your life harder.

Would anybody following along be opposed to a situation where
- dynamiclib builds go through the dlopen() shim
- staticlib builds always rely on statically linked symbols

Or do we need to be able to mix and match?

--Jacob

---

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

Hi,

> of libpq. For Tom, I think it was the dependency additions.

I'd say that curl's security reputation is higher than most of our other
dependencies. We have dependencies for libraries with regular security issues,
with those issues at times not getting addressed for prolonged amounts of
time.

I do agree that there's an issue increasing libpq's indirect footprint
substantially, but I don't think that's due to curl's reputation or
anything. It's just needing a significantly higher number of shared libraries,
which comes with runtime and distribution overhead.

Greetings,

Andres Freund

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 8 Apr 2025 14:25:20 -0400

> with those issues at times not getting addressed for prolonged amounts of

I see curl CVEs regularly as part of Debian minor updates, which is why
I had concerns, but if it is similar to OpenSSL, and better than other
libraries that don't even get CVEs, I guess it okay.  However, is this
true for libpq libraries or database server libraries.  Does it matter?

---

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

On Tue, Apr 8, 2025 at 11:25 AM Bruce Momjian <[email-masked]> wrote:
> However, is this

The dependency on Curl is through libpq. We have some server-side
features that pull in libpq and would transitively depend on Curl. But
for Curl to be initialized server-side, the two peers still have to
agree on the use of OAuth.

It seems unlikely that users would opt into that for, say,
postgres_fdw in PG18, because the Device Authorization flow is the
only one we currently ship, and it's intended for end users. A flow
that prints a code to stderr is not very helpful for your proxy.

--Jacob

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 11 Apr 2025 19:32:31 +0200

> - staticlib builds always rely on statically linked symbols

If this can be implemented in a straightforward way, that would be the 
best way, I think.