public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Jacob Champion <[email protected]>
Subject: Re: disabled SSL log_like tests
Date: Wed, 07 May 2025 17:27:11 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKGLO=rq8iy0zwLHO9Kxv=vsB+b=XQg0Wn9TunuQj1=v5Bw@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CA+hUKG+fLqyweHqFSBcErueUVT0vDuSNWui-ySz3+d_APmq7dw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+hUKGJkUJAwckjBr-=B9oUdDgjSEH+3njd__OnPoPuAtze3Qg@mail.gmail.com>
<[email protected]>
<CA+hUKGLO=rq8iy0zwLHO9Kxv=vsB+b=XQg0Wn9TunuQj1=v5Bw@mail.gmail.com>
Thomas Munro <[email protected]> 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
view thread (30+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: disabled SSL log_like tests
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox