Content-Type: multipart/alternative;
 boundary="------------tp0geFvzhhQMRtg6Y3YJeEbi"
Message-ID: <bf7c3396-a9a2-4df7-aabd-6fed387e027b@technowledgy.de>
Date: Tue, 8 Apr 2025 18:32:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Content-Language: en-US
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Bruce Momjian <bruce@momjian.us>, Daniel Gustafsson <daniel@yesql.se>,
 Christoph Berg <myon@debian.org>, Andres Freund <andres@anarazel.de>,
 Peter Eisentraut <peter@eisentraut.org>, Tom Lane <tgl@sss.pgh.pa.us>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 Thomas Munro <thomas.munro@gmail.com>, Nazir Bilal Yavuz
 <byavuz81@gmail.com>, Antonin Houska <ah@cybertec.at>
References: <CAOYmi+moTsgohh5Tf1gn7dBynARV9EFfWaBVPcJD9O=h6RkSCw@mail.gmail.com>
 <5bec3d4f-613f-425b-88c4-59e71c70f7d6@eisentraut.org>
 <t66lxwxgaxinug7zr4pgf72anhzkqwgrudmqnczgjdu4rv3ll5@jkcxvyvkgcqc>
 <CAOYmi+kc=YXZvZ8YtSPRt57N1Tp9_gRwyXfMO5TJYtCLnEXo1A@mail.gmail.com>
 <Z_QdtqYmSggALamF@msg.df7cb.de>
 <CAOYmi+=YjmfJ+U6RTHfiXEFt9xJzaHnnbNSgSKahWr774_xGdA@mail.gmail.com>
 <Z_RKf5IPsxD6YHCn@msg.df7cb.de>
 <CAOYmi+kt5UvPOXXXT9w_nHBNgcqiTQWS2j=D9qJaewvmO4iaAg@mail.gmail.com>
 <CAOYmi+m2-2TH5AP7-8Knm_gcSiEaZVPGeUkfZeCLmYH395MYgA@mail.gmail.com>
 <B2A4AB83-C99D-4DF7-A310-50BF857739DA@yesql.se> <Z_Uzde7a1lCFaqfW@momjian.us>
 <CAOYmi+mrYnuwMEnpYWA4FWFtDCe4rMKavDrKQPpV43u=zmR8Xg@mail.gmail.com>
 <96b5b38b-2fac-409f-b922-f7fd653bf847@technowledgy.de>
 <CAOYmi+m-q8VOPsFxB3D-CWf-T057h4XLqVPvCTudXyAj7-9vpA@mail.gmail.com>
From: Wolfgang Walther <walther@technowledgy.de>
In-Reply-To: <CAOYmi+m-q8VOPsFxB3D-CWf-T057h4XLqVPvCTudXyAj7-9vpA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/bf7c3396-a9a2-4df7-aabd-6fed387e027b%40technowledgy.de>
Precedence: bulk

This is a multi-part message in MIME format.
--------------tp0geFvzhhQMRtg6Y3YJeEbi
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Jacob Champion:
> 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?

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.

--------------tp0geFvzhhQMRtg6Y3YJeEbi
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Jacob Champion:<span
      style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
cite="mid:CAOYmi+m-q8VOPsFxB3D-CWf-T057h4XLqVPvCTudXyAj7-9vpA@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">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?
</pre>
    </blockquote>
    <p>When linking statically, I am producing entirely statically
      linked single binaries. Those contain libpq, all other
      dependencies, and would also contain curl.</p>
    <p>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.</p>
    <p>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.</p>
    <p>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? *</p>
    <p>Best,</p>
    <p>Wolfgang</p>
    <p>* 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.</p>
  </body>
</html>

--------------tp0geFvzhhQMRtg6Y3YJeEbi--