Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tulUr-00BPGL-7R for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Mar 2025 04:57:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tulUp-00D10a-Rn for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Mar 2025 04:57:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tulUp-00D10S-I4 for pgsql-hackers@lists.postgresql.org; Wed, 19 Mar 2025 04:57:39 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tulUm-003hIh-0b for pgsql-hackers@postgresql.org; Wed, 19 Mar 2025 04:57:39 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 52J4vTkj641688; Wed, 19 Mar 2025 00:57:30 -0400 From: Tom Lane To: Thomas Munro cc: Jacob Champion , Nazir Bilal Yavuz , Andres Freund , Daniel Gustafsson , Peter Eisentraut , Antonin Houska , PostgreSQL Hackers Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER In-reply-to: References: <83C44AB4-24B0-437F-B139-B5CBC5821BB1@yesql.se> <2A1511A0-C04B-47E4-B1C3-54C2A1C765B8@yesql.se> <13F329B6-86BC-40A5-96F4-102784A0357A@yesql.se> <636879.1742357835@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Wed, 19 Mar 2025 17:34:18 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <641686.1742360249.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Mar 2025 00:57:29 -0400 Message-ID: <641687.1742360249@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk BTW, I was pretty seriously disheartened just now to realize that this feature was implemented by making libpq depend on libcurl. I'd misread the relevant commit messages to say that libcurl was just being used as test infrastructure; but nope, it's a genuine build and runtime dependency. I wonder how much big-picture thinking went into that. I can see at least two objections: * This represents a pretty large expansion of dependency footprint, not just for us but for the umpteen hundred packages that depend on libpq. libcurl alone maybe wouldn't be so bad, but have you looked at libcurl's dependencies? On RHEL8, $ ldd /usr/lib64/libcurl.so.4.5.0 linux-vdso.so.1 (0x00007fffd3075000) libnghttp2.so.14 =3D> /lib64/libnghttp2.so.14 (0x00007f992097a000) libidn2.so.0 =3D> /lib64/libidn2.so.0 (0x00007f992075c000) libssh.so.4 =3D> /lib64/libssh.so.4 (0x00007f99204ec000) libpsl.so.5 =3D> /lib64/libpsl.so.5 (0x00007f99202db000) libssl.so.1.1 =3D> /lib64/libssl.so.1.1 (0x00007f9920046000) libcrypto.so.1.1 =3D> /lib64/libcrypto.so.1.1 (0x00007f991fb5b000) libgssapi_krb5.so.2 =3D> /lib64/libgssapi_krb5.so.2 (0x00007f991f9= 06000) libkrb5.so.3 =3D> /lib64/libkrb5.so.3 (0x00007f991f61b000) libk5crypto.so.3 =3D> /lib64/libk5crypto.so.3 (0x00007f991f404000) libcom_err.so.2 =3D> /lib64/libcom_err.so.2 (0x00007f991f200000) libldap-2.4.so.2 =3D> /lib64/libldap-2.4.so.2 (0x00007f991efb1000) liblber-2.4.so.2 =3D> /lib64/liblber-2.4.so.2 (0x00007f991eda1000) libbrotlidec.so.1 =3D> /lib64/libbrotlidec.so.1 (0x00007f991eb9400= 0) libz.so.1 =3D> /lib64/libz.so.1 (0x00007f991e97c000) libpthread.so.0 =3D> /lib64/libpthread.so.0 (0x00007f991e75c000) libc.so.6 =3D> /lib64/libc.so.6 (0x00007f991e386000) libunistring.so.2 =3D> /lib64/libunistring.so.2 (0x00007f991e00500= 0) librt.so.1 =3D> /lib64/librt.so.1 (0x00007f991ddfd000) /lib64/ld-linux-x86-64.so.2 (0x00007f9920e30000) libdl.so.2 =3D> /lib64/libdl.so.2 (0x00007f991dbf9000) libkrb5support.so.0 =3D> /lib64/libkrb5support.so.0 (0x00007f991d9= e8000) libkeyutils.so.1 =3D> /lib64/libkeyutils.so.1 (0x00007f991d7e4000) libresolv.so.2 =3D> /lib64/libresolv.so.2 (0x00007f991d5cc000) libsasl2.so.3 =3D> /lib64/libsasl2.so.3 (0x00007f991d3ae000) libm.so.6 =3D> /lib64/libm.so.6 (0x00007f991d02c000) libbrotlicommon.so.1 =3D> /lib64/libbrotlicommon.so.1 (0x00007f991= ce0b000) libselinux.so.1 =3D> /lib64/libselinux.so.1 (0x00007f991cbe0000) libcrypt.so.1 =3D> /lib64/libcrypt.so.1 (0x00007f991c9b7000) libpcre2-8.so.0 =3D> /lib64/libpcre2-8.so.0 (0x00007f991c733000) * Given libcurl's very squishy portfolio: libcurl is a free and easy-to-use client-side URL transfer library, supp= orting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS, FILE= , IMAP, SMTP, POP3 and RTSP. libcurl supports SSL certificates, HTTP POST, HTTP = PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, Kerberos4), file transfe= r resume, http proxy tunneling and more. it's not exactly hard to imagine them growing a desire to handle "postgresql://" URLs, which they would surely do by invoking libpq. Then we'll have circular build dependencies and circular runtime dependencies, not to mention inter-library recursion at runtime. This is not quite a hill that I wish to die on, but I will flatly predict that we will regret this. regards, tom lane