Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0
От | Tom Lane |
---|---|
Тема | Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0 |
Дата | |
Msg-id | 635760.1644108785@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0
Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0 |
Список | pgsql-bugs |
I wrote: > I don't have any theory about why "host=localhost" helps. Hah: now I do. The initial connection string set up by Cluster.pm is something like Connection string: port=65130 host=/tmp/ShNzQo5mRv and we happily pass that bogus host name to SSL_set_tlsext_host_name. Apparently, openssl takes such a bogus setting in stride, but libressl not so much. It's not entirely clear to me why this doesn't cause *every* connection attempt to fail, but at any rate Daniel's hack causes this to be overridden with "localhost", keeping SSL_set_tlsext_host_name happy. You can get the same results by setting host='' instead (preventing SSL_set_tlsext_host_name from being called at all). I'd backed into this by diking out the SSL_set_tlsext_host_name call altogether and finding that that also makes the tests pass (after groveling through the libpq source code and finding that that's basically the only way we could be exposing the host setting to libressl). I'd recommend using host='' in the tests, as that more or less replicates what the test author probably expected to happen. The seeming timing problem with the two CRL tests remains. regards, tom lane
В списке pgsql-bugs по дате отправления: