On Sun, Mar 17, 2019 at 2:00 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Wed, Mar 6, 2019 at 9:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Yeah, I've still been unable to reproduce even with the sleep idea,
> > so eelpout is definitely looking like a special snowflake from here.
> > In any case, there seems little doubt that getting past SSL_connect()
> > when the cert check has failed is an OpenSSL bug; I don't feel a need
> > to create a workaround for it.
>
> I was wrong: it breaks on an x86 system for me too (either with the
> sleep, or with clunky scheduling, I was running psql under strace when
> I saw it). Not sure what I did wrong last time I tried that. I
> opened a bug report with OpenSSL, let's see what they say:
>
> https://github.com/openssl/openssl/issues/8500
This was an intentional change in TLS1.3, reducing round trips by
verifying the client certificate later.
I'm pretty sure the fix I mentioned earlier -- namely adding an ad-hoc
call to pqHandleSendFailure() if we fail to send the start-up packet
-- would fix eelpout's measles (though obviously wouldn't solve the
problem for Windows given what we have learned about its TCP
implementation). I should probably go and do that, unless you want to
write the more general handling for send failure you described, and
are prepared to back-patch it?
--
Thomas Munro
https://enterprisedb.com
