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 <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1uCmIR-0026O2-Gi
	for pgsql-hackers@arkaria.postgresql.org; Wed, 07 May 2025 21:27:19 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1uCmIQ-00GQCH-DU
	for pgsql-hackers@arkaria.postgresql.org; Wed, 07 May 2025 21:27:18 +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 <tgl@sss.pgh.pa.us>)
	id 1uCmIQ-00GQC9-3t
	for pgsql-hackers@lists.postgresql.org; Wed, 07 May 2025 21:27:18 +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 <tgl@sss.pgh.pa.us>)
	id 1uCmIN-000hL5-11
	for pgsql-hackers@postgresql.org;
	Wed, 07 May 2025 21:27:17 +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 547LRBq0076776;
	Wed, 7 May 2025 17:27:11 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Andrew Dunstan <andrew@dunslane.net>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>,
        Jacob Champion <jacob.champion@enterprisedb.com>
Subject: Re: disabled SSL log_like tests
In-reply-to: 
 <CA+hUKGLO=rq8iy0zwLHO9Kxv=vsB+b=XQg0Wn9TunuQj1=v5Bw@mail.gmail.com>
References: <984fca80-85a8-4c6f-a5cc-bb860950b435@dunslane.net>
 <2199758.1744901785@sss.pgh.pa.us>
 <1ce11d3f-624c-4003-a032-1b10cc138305@dunslane.net>
 <2814408.1745005558@sss.pgh.pa.us> <2859105.1745015195@sss.pgh.pa.us>
 <1120735.1745350422@sss.pgh.pa.us>
 <CA+hUKG+fLqyweHqFSBcErueUVT0vDuSNWui-ySz3+d_APmq7dw@mail.gmail.com>
 <3058990.1746485124@sss.pgh.pa.us> <3227092.1746580691@sss.pgh.pa.us>
 <CA+hUKGJkUJAwckjBr-=B9oUdDgjSEH+3njd__OnPoPuAtze3Qg@mail.gmail.com>
 <3248136.1746592452@sss.pgh.pa.us>
 <CA+hUKGLO=rq8iy0zwLHO9Kxv=vsB+b=XQg0Wn9TunuQj1=v5Bw@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Wed, 07 May 2025 16:58:03 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <76774.1746653231.1@sss.pgh.pa.us>
Date: Wed, 07 May 2025 17:27:11 -0400
Message-ID: <76775.1746653231@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/76775.1746653231%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> Oh, interesting.  I also wondered if the problem I reported might be
> related to the separate legacy code paths in x509_vfy.c.

I poked at this a little more, and apparently the code to look at is
actually in the sibling file x509_verify.c.  Here's the backtrace
(in OpenBSD 7.7) from where we construct the incorrect report:

#0  verify_cb (ok=0, ctx=0x17d83e77c00) at be-secure-openssl.c:1213
#1  0x0000017ce17483dc in x509_verify (ctx=0x17d1886f700, leaf=0x17d188882a0, 
    name=0x0) at /usr/src/lib/libcrypto/x509/x509_verify.c:1271
#2  0x0000017ce16ed683 in _lcry_X509_verify_cert (ctx=0x17d83e77c00)
    at /usr/src/lib/libcrypto/x509/x509_vfy.c:645
#3  0x0000017d44ebc4e3 in ssl_verify_cert_chain (s=0x17d83e96500, 
    certs=0x17d83e5fce0) at /usr/src/lib/libssl/ssl_cert.c:437
#4  0x0000017d44eb3d13 in tls13_client_certificate_recv (ctx=0x17d18881f00, 
    cbs=<optimized out>) at /usr/src/lib/libssl/tls13_server.c:918
#5  0x0000017d44ee8d66 in tls13_handshake_recv_action (ctx=0x17d18881f00, 
    action=0x17d44ef6dd0 <state_machine+352>)
    at /usr/src/lib/libssl/tls13_handshake.c:549
#6  tls13_handshake_perform (ctx=0x17d18881f00)
    at /usr/src/lib/libssl/tls13_handshake.c:412
#7  0x0000017d44eb18c7 in tls13_legacy_accept (ssl=0x17d83e96500)
    at /usr/src/lib/libssl/tls13_legacy.c:434
#8  0x0000017a8bbd6f3a in be_tls_open_server (port=0x17d6d91f9b0)
    at be-secure-openssl.c:494
#9  0x0000017a8bbc41c8 in secure_open_server (port=0x17d6d91f9b0)
    at be-secure.c:136
#10 0x0000017a8be9d79e in ProcessStartupPacket (port=0x17d6d91f9b0, 
    ssl_done=false, gss_done=false) at backend_startup.c:614

The code in x509_verify() is about as convoluted as can be:
it seems to be dealing with two different verify-callback APIs
(and naturally, the one we are using is the legacy one).
There is some stuff there that saves and restores an error
condition, but fails to save/restore current_cert, so the first
thing I thought was that that was the problem --- but it's not,
the current_cert doesn't change anyway between the save and the
restore.  So I failed to identify exactly where the problem is,
but I wonder if it'd behave better if we switched to their
new-style callback API.

			regards, tom lane