Re: Rare SSL failures on eelpout
От | Thomas Munro |
---|---|
Тема | Re: Rare SSL failures on eelpout |
Дата | |
Msg-id | CA+hUKGKb=1FJadFhzQCMWbt14e0gJfM+TpXFEbf=kH2fsHQxBg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rare SSL failures on eelpout (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Rare SSL failures on eelpout
|
Список | pgsql-hackers |
On Wed, Mar 6, 2019 at 9:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. 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 -- Thomas Munro https://enterprisedb.com
В списке pgsql-hackers по дате отправления: