Re: disabled SSL log_like tests

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