On 2025-03-20 Th 7:26 PM, Andres Freund wrote:
Hi,
On 2025-03-20 17:08:54 -0400, Tom Lane wrote:
Bruce Momjian <br...@momjian.us> writes:
On Thu, Mar 20, 2025 at 01:33:26PM -0700, Jacob Champion wrote:
So one question for the collective is -- putting Curl itself aside --
is having a basic-but-usable OAuth flow, out of the box, worth the
costs of a generic HTTP client?
One observation is that security scanning tools are going to see the
curl dependency and look at any CSVs related to them and ask us, whether
they are using OAUTH or not.
Yes. Also, none of this has addressed my complaint about the extent
of the build and install dependencies. Yes, simply not selecting
--with-libcurl removes the problem ... but most packagers are under
very heavy pressure to enable all features of a package.
How about we provide the current libpq.so without linking to curl and also a
libpq-oauth.so that has curl support? If we do it right libpq-oauth.so would
itself link to libpq.so, making libpq-oauth.so a fairly small library.
That way packagers can split libpq-oauth.so into a separate package, while
still just building once.
That'd be a bit of work on the buildsystem side, but it seems doable.
That certainly seems worth exploring.
From what's been said here, only a small minority of users are likely
to have any interest in this feature. So my answer to "is it worth
the cost" is no, and would be no even if I had a lower estimate of
the costs.
I think this is likely going to be rather widely used, way more widely than
e.g. kerberos or ldap support in libpq. My understanding is that there's a
fair bit of pressure in lots of companies to centralize authentication towards
centralized systems, even for server applications.
Indeed. There is still work to do on OAUTH2 but the demand you mention
is just going to keep increasing.
I don't have any problem with making a solution available to those
users who want it --- but I really do NOT want this to be part of
stock libpq nor done as part of the core Postgres build. I do not
think that the costs of that have been fully accounted for, especially
not the fact that almost all of those costs fall on people other than
us.
I am on board with not having it as part of stock libpq, but I don't see what
we gain by not building it as part of postgres (if the dependencies are
available, of course).
+1.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
