Re: disabled SSL log_like tests

Thomas Munro <thomas(dot)munro(at)gmail(dot)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