Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1odzxW-0001bU-4X for pgsql-bugs@arkaria.postgresql.org; Thu, 29 Sep 2022 20:16:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1odzxT-0003Bw-V8 for pgsql-bugs@arkaria.postgresql.org; Thu, 29 Sep 2022 20:16:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1odzxT-0003Bm-NP for pgsql-bugs@lists.postgresql.org; Thu, 29 Sep 2022 20:16:35 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1odzxR-0005DO-Jt for pgsql-bugs@lists.postgresql.org; Thu, 29 Sep 2022 20:16:34 +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 28TKGVDO360380; Thu, 29 Sep 2022 16:16:31 -0400 From: Tom Lane To: heath.lord@crunchydata.com cc: Daniel Gustafsson , Jacob Champion , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17625: In PG15 PQsslAttribute returns different values than PG14 when SSL is not in use for the connection In-reply-to: <346263.1664480998@sss.pgh.pa.us> References: <17625-fc47c78b7d71b534@postgresql.org> <346263.1664480998@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 29 Sep 2022 15:49:58 -0400" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <360369.1664482580.0@sss.pgh.pa.us> Date: Thu, 29 Sep 2022 16:16:31 -0400 Message-ID: <360379.1664482591@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <360369.1664482580.1@sss.pgh.pa.us> I wrote: > AFAICS that behavioral change is deliberate: for the single case > of inquiring about "library", PQsslAttribute now tells you which > SSL implementation libpq *can* use, not which one it's actually > using on a given connection. I'm not sure that this is a great > definition, since it's so unlike the behavior for other attributes. Actually, wait a minute: both the documentation and the commit message claim the new behavior is something different than what it actually is. The intention seems to have been to change the behavior only for the conn == NULL case. So maybe we need to fix it as attached. This'd still be broken for the multiple-libraries scenario, but I admit that that's pretty hypothetical. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="fix-broken-PQsslAttribute.patch"; charset="us-ascii" Content-ID: <360369.1664482580.2@sss.pgh.pa.us> Content-Description: fix-broken-PQsslAttribute.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/interfaces/libpq/fe-secure-openssl.c b/src/interfaces/lib= pq/fe-secure-openssl.c index aea4661736..e2eace2bc6 100644 --- a/src/interfaces/libpq/fe-secure-openssl.c +++ b/src/interfaces/libpq/fe-secure-openssl.c @@ -1745,14 +1745,18 @@ PQsslAttributeNames(PGconn *conn) const char * PQsslAttribute(PGconn *conn, const char *attribute_name) { - if (strcmp(attribute_name, "library") =3D=3D 0) - return "OpenSSL"; - if (!conn) + { + if (strcmp(attribute_name, "library") =3D=3D 0) + return "OpenSSL"; return NULL; + } if (conn->ssl =3D=3D NULL) return NULL; = + if (strcmp(attribute_name, "library") =3D=3D 0) + return "OpenSSL"; + if (strcmp(attribute_name, "key_bits") =3D=3D 0) { static char sslbits_str[12]; ------- =_aaaaaaaaaa0--