BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA=&#39;ssl&#39; options, SSL tests fail on OpenBSD 7.0

andres@anarazel.de

about 4 years ago

In reply to: PG Bug reporting form (#1)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Hi,

Daniel, Heikki, Michael CCing you as you seem to have worked most on those
tests and libressl fixes.

On 2022-02-02 19:19:22 +0000, PG Bug reporting form wrote:

While installing PostgreSQL from source code, SSL tests fail on OpenBSD
7.0.

OpenSSL Version:
LibreSSL 3.4.1

Do we expect the SSL tests to pass when using libressl? If not, we should make
the ssl tests SKIP when using libressl...

Greetings,

Andres Freund

Thomas Munro

thomas.munro@gmail.com

about 4 years ago

In reply to: Andres Freund (#2)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

On Thu, Feb 3, 2022 at 10:39 AM Andres Freund <andres@anarazel.de> wrote:

Daniel, Heikki, Michael CCing you as you seem to have worked most on those
tests and libressl fixes.

I guess the previous commits mentioning libressl were just getting it
to compile on OpenBSD? Very few BF animals actually run the ssl tests
(which requires setting PG_TEST_EXTRA="ssl"). That said, people are
definitely running PostgreSQL with SSL on OpenBSD in the wild, so it's
at least partially working. I wonder if the problem is something that
needs to be configured in /etc/ssl/openssl.cnf (something like
https://obsd.solutions/en/blog/2020/06/08/libressl-error-due-to-missing-v3_ca-in-extension/
though that doesn't seem to be it).

Anyway, I can also reproduce this problem on my Vagrant image (OpenBSD
6.9 'cause I haven't got around to setting up 7). Just in case it
helps someone who (unlike me) knows enough about libressl to debug
this and knows how to drive vagrant, here's a reproducer:

git clone https://github.com/macdice/postgresql-dev-vagrant.git
cd postgresql-dev-vagarant/openbsd6
vagrant up
... wait for installation and build ...
vagrant ssh
cd postgres/src/test/ssl
gmake check

tgl@sss.pgh.pa.us

about 4 years ago

In reply to: Thomas Munro (#3)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Thomas Munro <thomas.munro@gmail.com> writes:

Anyway, I can also reproduce this problem on my Vagrant image (OpenBSD
6.9 'cause I haven't got around to setting up 7).

I had an OpenBSD 6.8 image laying about, so I tried the ssl test
there, and it falls over in even more places:

Test Summary Report
-------------------
t/001_ssltests.pl (Wstat: 8448 Tests: 110 Failed: 33)
Failed tests: 14, 16, 18-20, 28, 30-32, 58, 60, 72-76
79-83, 88-90, 94-95, 97, 99, 102, 104, 106
108, 110
Non-zero exit status: 33
t/002_scram.pl (Wstat: 1792 Tests: 11 Failed: 7)
Failed tests: 1, 4-5, 7, 9-11
Non-zero exit status: 7
t/003_sslinfo.pl (Wstat: 7424 Tests: 1 Failed: 1)
Failed test: 1
Non-zero exit status: 29
Parse errors: Bad plan. You planned 13 tests but ran 1.

A lot of the errors look like they didn't yet have support for
TLS 1.2; this is typical:

# Failed test 'pg_stat_ssl with client certificate: no stderr'
# at t/001_ssltests.pl line 523.
# got: 'psql: error: connection to server at "127.0.0.1", port 57105 failed: SSL error: tlsv1 alert protocol version
# This may indicate that the server does not support any SSL protocol version between TLSv1.2 and TLSv1.2.

The postmaster log entries corresponding to this look like

2022-02-02 20:13:49.420 EST [16352] [unknown] LOG: connection received: host=localhost port=39596
2022-02-02 20:13:49.429 EST [16352] [unknown] LOG: could not accept SSL connection: sslv3 alert illegal parameter

I don't see anything in /etc/ssl/openssl.cnf that looks related
to TLS protocol restrictions.

Perhaps 6.8 is too old to be of interest anymore, but that's
what I've got handy.

BTW, I also reproduced something that seems odd from the OP's
postmaster logs: there are what seem a quite excessive number
of checkpoints happening during these tests. That happens
on my Linux box too, so it's not an OpenBSD issue. It looks
like there are two per CREATE DATABASE --- I could understand
one maybe, but why two?

regards, tom lane

andres@anarazel.de

about 4 years ago

In reply to: Tom Lane (#4)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Hi,

On 2022-02-02 20:31:52 -0500, Tom Lane wrote:

BTW, I also reproduced something that seems odd from the OP's
postmaster logs: there are what seem a quite excessive number
of checkpoints happening during these tests. That happens
on my Linux box too, so it's not an OpenBSD issue. It looks
like there are two per CREATE DATABASE --- I could understand
one maybe, but why two?

I think that's unfortunately normal. There's two RequestCheckpoint()s in
createdb(). We should optimize that someday...

Greetings,

Andres Freund

tgl@sss.pgh.pa.us

about 4 years ago

In reply to: Andres Freund (#5)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Andres Freund <andres@anarazel.de> writes:

On 2022-02-02 20:31:52 -0500, Tom Lane wrote:

BTW, I also reproduced something that seems odd from the OP's
postmaster logs: there are what seem a quite excessive number
of checkpoints happening during these tests. That happens
on my Linux box too, so it's not an OpenBSD issue. It looks
like there are two per CREATE DATABASE --- I could understand
one maybe, but why two?

I think that's unfortunately normal. There's two RequestCheckpoint()s in
createdb(). We should optimize that someday...

Hmm. I wonder how much that slows down a check-world run.
I suppose the second checkpoint should be pretty speedy
for lack of anything to do, but still ...

regards, tom lane

https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/36/3314
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/36/3192

andres@anarazel.de

about 4 years ago

In reply to: Tom Lane (#6)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Hi,

On 2022-02-02 21:44:41 -0500, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2022-02-02 20:31:52 -0500, Tom Lane wrote:

BTW, I also reproduced something that seems odd from the OP's
postmaster logs: there are what seem a quite excessive number
of checkpoints happening during these tests. That happens
on my Linux box too, so it's not an OpenBSD issue. It looks
like there are two per CREATE DATABASE --- I could understand
one maybe, but why two?

I think that's unfortunately normal. There's two RequestCheckpoint()s in
createdb(). We should optimize that someday...

Hmm. I wonder how much that slows down a check-world run.
I suppose the second checkpoint should be pretty speedy
for lack of anything to do, but still ...

There is a patch making CREATE DATABASE fully WAL logged [1]https://commitfest.postgresql.org/36/3192/.

cfbot timings aren't super reliable, but it provides perhaps a bit of
information.

It does seem to make individual create databases a bit faster. Comparing runs
with another patch and looking at windows (since that's the slowest and
doesn't run regression tests concurrently), we can see:

CF 3314:
[01:28:31.630] Checking plpgsql
[01:28:31.764] ============== creating database "pl_regression" ==============
[01:28:32.631] CREATE DATABASE

[01:28:36.515] Checking plperl
[01:28:36.751] ============== creating database "pl_regression" ==============
[01:28:37.560] CREATE DATABASE

[01:28:40.990] Checking plpythonu
[01:28:41.233] ============== creating database "pl_regression" ==============
[01:28:42.057] CREATE DATABASE

CF 3192:
[07:03:54.861] Checking plpgsql
[07:03:54.986] ============== creating database "pl_regression" ==============
[07:03:55.254] CREATE DATABASE

[07:03:58.950] Checking plperl
[07:03:59.234] ============== creating database "pl_regression" ==============
[07:03:59.484] CREATE DATABASE

[07:04:02.724] Checking plpythonu
[07:04:02.960] ============== creating database "pl_regression" ==============
[07:04:03.202] CREATE DATABASE

Which does seem to suggest createdb being noticably faster.

This is also visible in aggregate across several tests, e.g. "test_modules"
averaging ~45s for 36/3314, but ~30s for 36/3192.

For the longer running tap tests it doesn't seem to make much of a difference,
which make some sense.

Greetings,

Andres Freund

[1]: https://commitfest.postgresql.org/36/3192/

tgl@sss.pgh.pa.us

about 4 years ago

In reply to: Tom Lane (#4)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

I wrote:

I had an OpenBSD 6.8 image laying about, so I tried the ssl test
there, and it falls over in even more places:
...
A lot of the errors look like they didn't yet have support for
TLS 1.2; this is typical:

On further investigation, that's nonsense, because the postmaster logs
show that most if not all of the connections that are succeeding are
TLSv1.3, eg

2022-02-02 21:31:07.492 EST [96067] [unknown] LOG: 00000: connection authorized: user=ssltestuser database=trustdb application_name=001_ssltests.pl SSL enabled (protocol=TLSv1.3, cipher=AEAD-AES256-GCM-SHA384, bits=256)

However, PG believes that the library only supports up to 1.2,
because TLS1_3_VERSION isn't defined. I found this in
/usr/include/openssl/tls1.h:

#if defined(LIBRESSL_HAS_TLS1_3) || defined(LIBRESSL_INTERNAL)
#define TLS1_3_VERSION 0x0304
#endif

LIBRESSL_HAS_TLS1_3 is not defined anywhere; in
/usr/include/openssl/opensslfeatures.h I find

/*
* Feature flags for LibreSSL... so you can actually tell when things
* are enabled, rather than not being able to tell when things are
* enabled (or possibly not yet not implemented, or removed!).
*/
/* #define LIBRESSL_HAS_TLS1_3 */

which is about the best example I've seen lately of crappy code
falsifying the adjacent comment.

I added

#define LIBRESSL_HAS_TLS1_3 1

to pg_config.h to see what would happen. It seems that about
the same number of tests fall over, but now the errors are
(mostly) not about TLS version. Some look like they might
just be mismatched expectations of exactly what error will
be issued:

# Failed test 'connect with wrong server root cert sslmode=require: matches'
# at t/001_ssltests.pl line 170.
# 'psql: error: connection to server at "127.0.0.1", port 62542 failed: SSL error: tlsv1 alert unknown ca'
# doesn't match '(?^:SSL error: certificate verify failed)'

I get the impression though that there's still some mismatch
about how to establish which CAs are trusted, and there are
still a few "tlsv1 alert protocol version" errors with no
obvious reason.

I thought for awhile that the library might be forcing a minimum
TLS version of 1.3 (despite the headers not even claiming to
support it at all), because that would fit right in with OpenBSD's
securer-than-thou ethos. I still suspect that something like that
might be going on, but I don't have hard evidence.

regards, tom lane

[0]: https://github.com/libressl-portable/portable/issues/228

daniel@yesql.se

about 4 years ago

In reply to: Tom Lane (#8)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

On 3 Feb 2022, at 06:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:

However, PG believes that the library only supports up to 1.2,
because TLS1_3_VERSION isn't defined. I found this in
/usr/include/openssl/tls1.h:

#if defined(LIBRESSL_HAS_TLS1_3) || defined(LIBRESSL_INTERNAL)
#define TLS1_3_VERSION 0x0304
#endif

LIBRESSL_HAS_TLS1_3 is not defined anywhere; in
/usr/include/openssl/opensslfeatures.h I find

/*
* Feature flags for LibreSSL... so you can actually tell when things
* are enabled, rather than not being able to tell when things are
* enabled (or possibly not yet not implemented, or removed!).
*/
/* #define LIBRESSL_HAS_TLS1_3 */

which is about the best example I've seen lately of crappy code
falsifying the adjacent comment.

AFAICT from reading their (not too extensive) docs is that they consider 1.3
supporting starting with 3.4 which supports the OpenSSL 1.1.1 API. Recent
reports [0]https://github.com/libressl-portable/portable/issues/228 on their -portable Github repo are saying it still doesn't work. I
haven't dug too far in to this yet, but will have a look.

Adding host=localhost to the connection string in the tests make all the tests
but two pass for me:

t/001_ssltests.pl .. 93/110
# Failed test 'certificate authorization fails with revoked client cert: matches'
# at t/001_ssltests.pl line 565.
# 'psql: error: connection to server at "127.0.0.1", port 50547 failed: server closed the connection unexpectedly
# This probably means the server terminated abnormally
# before or while processing the request.
# SSL SYSCALL error: Broken pipe'
# doesn't match '(?^:SSL error: sslv3 alert certificate revoked)'

# Failed test 'certificate authorization fails with revoked client cert with server-side CRL directory: matches'
# at t/001_ssltests.pl line 618.
# 'psql: error: connection to server at "127.0.0.1", port 50547 failed: server closed the connection unexpectedly
# This probably means the server terminated abnormally
# before or while processing the request.
# SSL SYSCALL error: Broken pipe
# connection to server at "127.0.0.1", port 50547 failed: FATAL: no pg_hba.conf entry for host "127.0.0.1", user "ssltestuser", database "certdb", no encryption'
# doesn't match '(?^:SSL error: sslv3 alert certificate revoked)'
# Looks like you failed 2 tests of 110.
t/001_ssltests.pl .. Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/110 subtests
t/002_scram.pl ..... ok
t/003_sslinfo.pl ... ok

The remaining tests are both CRL tests, but I haven't had time yet to dig into
why those are failing (the logs weren't terribly helpful on a quick glance).

--
Daniel Gustafsson https://vmware.com/

#10

daniel@yesql.se

about 4 years ago

In reply to: Daniel Gustafsson (#9)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Pouring over SSL test logs I was again red-herringed by the warning we get for
using hex() on a large input value, before I remembered that it's benign and
emerged from the rabbithole:

Hexadecimal number > 0xffffffff non-portable at t/001_ssltests.pl line 508.

We could suppress it by turning off warnings for that line, since we know it
will work due to the 64-bit int test a few lines before:

@@ -505,6 +505,7 @@ if ($? == 0)
        {
                $serialno =~ s/^serial=//;
                $serialno =~ s/\s+//g;
+               local $SIG{'__WARN__'} = sub { };
                $serialno = hex($serialno);
        }
        else

Turning of warnings might be a bridge too far for some though? Thoughts?

--
Daniel Gustafsson https://vmware.com/

#11

andres@anarazel.de

about 4 years ago

In reply to: Daniel Gustafsson (#10)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Hi,

On February 3, 2022 7:48:40 AM PST, Daniel Gustafsson <daniel@yesql.se> wrote:

Pouring over SSL test logs I was again red-herringed by the warning we get for
using hex() on a large input value, before I remembered that it's benign and
emerged from the rabbithole:

Hexadecimal number > 0xffffffff non-portable at t/001_ssltests.pl line 508.

We could suppress it by turning off warnings for that line, since we know it
will work due to the 64-bit int test a few lines before:
@@ -505,6 +505,7 @@ if ($? == 0)
{
$serialno =~ s/^serial=//;
$serialno =~ s/\s+//g;
+               local $SIG{'__WARN__'} = sub { };
$serialno = hex($serialno);
}
else
Turning of warnings might be a bridge too far for some though? Thoughts?

Can't we just chop serialno into two 32bit numbers and call hex separately? Seems about as hard as adding a comment explaining what the warn bit is about...

Andres

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

#12

daniel@yesql.se

about 4 years ago

In reply to: Andres Freund (#11)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

On 3 Feb 2022, at 16:55, Andres Freund <andres@anarazel.de> wrote:

Can't we just chop serialno into two 32bit numbers and call hex separately?
Seems about as hard as adding a comment explaining what the warn bit is
about...

That doesn't not make sense.. I'll look at that instead. Thanks.

--
Daniel Gustafsson https://vmware.com/

#13

tgl@sss.pgh.pa.us

about 4 years ago

In reply to: Daniel Gustafsson (#9)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Daniel Gustafsson <daniel@yesql.se> writes:

Adding host=localhost to the connection string in the tests make all the tests
but two pass for me:

FWIW, I see no change from that on 6.8.

regards, tom lane

#14

daniel@yesql.se

about 4 years ago

In reply to: Tom Lane (#13)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

On 3 Feb 2022, at 17:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Daniel Gustafsson <daniel@yesql.se> writes:

Adding host=localhost to the connection string in the tests make all the tests
but two pass for me:

FWIW, I see no change from that on 6.8.

Interesting. I realize that I forgot to mention that this was on a fresh
install of 7 with LibreSSL 3.4.2.

--
Daniel Gustafsson https://vmware.com/

#15

daniel@yesql.se

about 4 years ago

In reply to: Daniel Gustafsson (#9)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

On 3 Feb 2022, at 15:25, Daniel Gustafsson <daniel@yesql.se> wrote:

The remaining tests are both CRL tests, but I haven't had time yet to dig into
why those are failing (the logs weren't terribly helpful on a quick glance).

Looking at these remaining failures today left me a bit confused. It seems to
be some form of timing or synchronization issue as delaying shutdown with a
sleep(1) in the be_tls_open_server errorpath makes the tests pass. With the
attached diff I get all tests passing on OpenBSD 7. Following the bouncing
ball into differences between OpenSSL and LibreSSL in the revocation and
shutdown paths didn't lead to anything.

Does anyone have any ideas what this could be?

Thomas: Does the attached reproduce these results for you?

--
Daniel Gustafsson https://vmware.com/

#16

andres@anarazel.de

about 4 years ago

In reply to: Daniel Gustafsson (#15)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Hi,

On 2022-02-04 15:12:47 +0100, Daniel Gustafsson wrote:

Looking at these remaining failures today left me a bit confused. It seems to
be some form of timing or synchronization issue as delaying shutdown with a
sleep(1) in the be_tls_open_server errorpath makes the tests pass. With the
attached diff I get all tests passing on OpenBSD 7. Following the bouncing
ball into differences between OpenSSL and LibreSSL in the revocation and
shutdown paths didn't lead to anything.

Have you checked whether openssl on openbsd doesn't have this problem? It
could be an OS issue, rather than libressl.

Does anyone have any ideas what this could be?

I wonder if reverting 6051857fc and ed52c3707 makes a difference (like done in
the stable branches, due to windows issues)?

Greetings,

Andres Freund

#17

tgl@sss.pgh.pa.us

about 4 years ago

In reply to: Andres Freund (#16)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Andres Freund <andres@anarazel.de> writes:

I wonder if reverting 6051857fc and ed52c3707 makes a difference (like done in
the stable branches, due to windows issues)?

Sure hope not, because that code's inside #ifdef WIN32.

regards, tom lane

#18

Thomas Munro

thomas.munro@gmail.com

about 4 years ago

In reply to: Daniel Gustafsson (#15)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

On Sat, Feb 5, 2022 at 3:12 AM Daniel Gustafsson <daniel@yesql.se> wrote:

Thomas: Does the attached reproduce these results for you?

-bash-5.1$ uname -a
OpenBSD openbsd6.localdomain 6.9 GENERIC.MP#473 amd64
-bash-5.1$ openssl version
LibreSSL 3.3.2
-bash-5.1$ git rev-parse HEAD
b31e3f561365136b48d63e8561f32b697df16d1d
-bash-5.1$ curl -s
/messages/by-id/attachment/130677/kludge.diff |
patch -s -p1
-bash-5.1$ ./rebuild.sh
-bash-5.1$ gmake -s -C src/test/ssl check
t/001_ssltests.pl .. ok
t/002_scram.pl ..... ok
t/003_sslinfo.pl ... ok
All tests successful.
Files=3, Tests=134, 26 wallclock secs ( 0.18 usr 0.05 sys + 4.46
cusr 7.16 csys = 11.85 CPU)
Result: PASS

If I comment out your sleep(1), I get:

-bash-5.1$ gmake -s -C src/test/ssl check
t/001_ssltests.pl .. 80/110
# Failed test 'certificate authorization fails with revoked client
cert: matches'
# at t/001_ssltests.pl line 565.
# 'psql: error: connection to server at "127.0.0.1",
port 61927 failed: server closed the connection unexpectedly
# This probably means the server terminated abnormally
# before or while processing the request.
# SSL SYSCALL error: Broken pipe'
# doesn't match '(?^:SSL error: sslv3 alert certificate revoked)'
t/001_ssltests.pl .. 107/110
# Failed test 'certificate authorization fails with revoked client
cert with server-side CRL directory: matches'
# at t/001_ssltests.pl line 618.
# 'psql: error: connection to server at "127.0.0.1",
port 61927 failed: server closed the connection unexpectedly
# This probably means the server terminated abnormally
# before or while processing the request.
# SSL SYSCALL error: Broken pipe
# connection to server at "127.0.0.1", port 61927 failed: FATAL: no
pg_hba.conf entry for host "127.0.0.1", user "ssltestuser", database
"certdb", no encryption'
# doesn't match '(?^:SSL error: sslv3 alert certificate revoked)'
# Looks like you failed 2 tests of 110.
t/001_ssltests.pl .. Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/110 subtests
t/002_scram.pl ..... ok
t/003_sslinfo.pl ... ok

Test Summary Report
-------------------
t/001_ssltests.pl (Wstat: 512 Tests: 110 Failed: 2)
Failed tests: 97, 110
Non-zero exit status: 2
Files=3, Tests=134, 26 wallclock secs ( 0.07 usr 0.03 sys + 4.81
cusr 6.55 csys = 11.46 CPU)
Result: FAIL
gmake: *** [Makefile:32: check] Error 1

#19

andres@anarazel.de

about 4 years ago

In reply to: Andres Freund (#16)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

Hi,

On 2022-02-04 08:05:28 -0800, Andres Freund wrote:

Have you checked whether openssl on openbsd doesn't have this problem? It
could be an OS issue, rather than libressl.

FWIW, the ssl tests do pass with openssl, on openbsd 7.0, without any
patches. So it is a libressl related issue (although it can obviously be on
"our" side rather than "their" side).

Greetings,

Andres Freund

#20

Thomas Munro

thomas.munro@gmail.com

about 4 years ago

In reply to: Daniel Gustafsson (#15)

Re: BUG #17391: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL tests fail on OpenBSD 7.0

On Sat, Feb 5, 2022 at 3:12 AM Daniel Gustafsson <daniel@yesql.se> wrote:

Looking at these remaining failures today left me a bit confused. It seems to
be some form of timing or synchronization issue as delaying shutdown with a
sleep(1) in the be_tls_open_server errorpath makes the tests pass. With the
attached diff I get all tests passing on OpenBSD 7. Following the bouncing
ball into differences between OpenSSL and LibreSSL in the revocation and
shutdown paths didn't lead to anything.

Does anyone have any ideas what this could be?

usleep(1) is also enough, but usleep(0) isn't. I wonder if something
could be disabling SO_LINGER on the socket, or somehow activating
similar data-dropping behaviour so the final ereport doesn't get
transferred.

#21

tgl@sss.pgh.pa.us

about 4 years ago

In reply to: Daniel Gustafsson (#15)

#22

tgl@sss.pgh.pa.us

about 4 years ago

In reply to: Tom Lane (#21)

#23