Thomas Munro <thomas.munro@gmail.com> writes:
> Bleugh. I think this OpenSSL package might just be buggy on ARM. On
> x86, apparently the same version of OpenSSL and all other details of
> the test the same, I can see that SSL_connect() returns <= 0
> (failure), and then we ask for that cert revoked message directly and
> never even reach the startup packet sending code. On ARM,
> SSL_connect() returns 1 (success) and then we proceed as discussed and
> eventually get the error later (or not). So I think I should figure
> out a minimal repro and report this to them.
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.
The bug #15598 report is more troublesome, as we don't have a strong
reason to believe it's not common on Windows. However, I wonder whether
we can really do anything at all about that one. If I understand what
Andrew was hypothesizing in that thread, it was that Windows might be
dropping undelivered data on the floor once the server closes its end
of the connection. That would be totally broken behavior, but I never
expect anything else from Microsoft :-(. If that is an accurate theory
then rewriting libpq won't fix it.
I still think the redesign I suggested upthread would make things cleaner,
but I don't have time or interest to make it happen in the near future
if it's not fixing an observable bug.
regards, tom lane
