Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid warnings in tests when openssl binary isn't available

  1. "openssl" should not be optional

    Christoph Berg <myon@debian.org> — 2025-09-24T11:14:47Z

    Debian's reproducible-builds machinery has discovered a problem in the
SSL tests: When building with SSL support, but /usr/bin/openssl
missing (i.e "libssl-dev" installed, but "openssl" missing), the tests
fail in subtle ways:

checking for openssl... no
configure: using openssl: openssl not found
checking for openssl/ssl.h... yes
checking for openssl/err.h... yes

build/src/test/ssl/tmp_check/log/regress_log_001_ssltests:
Can't exec "x509": No such file or directory at t/001_ssltests.pl line 751.
couldn't run " x509" to get client cert serialno at t/001_ssltests.pl line 775.

build/src/test/ssl/tmp_check/log/regress_log_003_sslinfo:
[08:42:02.209](0.029s) ok 11 - ssl_client_serial() compared with pg_stat_ssl
psql:<stdin>:1: ERROR:  invalid X.509 field name: "invalid"
[08:42:02.238](0.029s) ok 12 - ssl_client_dn_field() for an invalid field

Full build log: https://reproduce.debian.net/amd64-pull184/api/v1/builds/66623/log

The problem does not show up on the normal Debian build daemons. While
the build environment there is fairly minimal, it does have "openssl"
preinstalled. So I cannot yet say if this problem is new in PG18, or
just never got detected in older branches.

While it is probably possible to skip the tests when the configure
probe did not find the openssl binary, IMHO the configure check should
already fail. That's more robust and easier.

Attached is a WIP patch that implements that for autoconf.

Christoph

  2. Re: "openssl" should not be optional

    Daniel Gustafsson <daniel@yesql.se> — 2025-09-24T11:22:28Z

    > On 24 Sep 2025, at 13:14, Christoph Berg <myon@debian.org> wrote:

> While it is probably possible to skip the tests when the configure
> probe did not find the openssl binary, IMHO the configure check should
> already fail. That's more robust and easier.

It seems a bit restrictive to require the openssl binary which is test-only,
since we allow building with ssl but without TAP support (which is where the
openssl binary is used).

--
Daniel Gustafsson

  3. Re: "openssl" should not be optional

    Christoph Berg <myon@debian.org> — 2025-09-24T11:37:23Z

    Re: Daniel Gustafsson
> It seems a bit restrictive to require the openssl binary which is test-only,
> since we allow building with ssl but without TAP support (which is where the
> openssl binary is used).

Ok, but then the error messages should be better. This was found
because a fellow Debian developer was smart enough to spot the extra
space in that " x509" error message... (And another one knew about
this difference between the different build environments.)

Christoph

  4. Re: "openssl" should not be optional

    Daniel Gustafsson <daniel@yesql.se> — 2025-09-24T11:40:22Z

    > On 24 Sep 2025, at 13:37, Christoph Berg <myon@debian.org> wrote:
> 
> Re: Daniel Gustafsson
>> It seems a bit restrictive to require the openssl binary which is test-only,
>> since we allow building with ssl but without TAP support (which is where the
>> openssl binary is used).
> 
> Ok, but then the error messages should be better. This was found
> because a fellow Debian developer was smart enough to spot the extra
> space in that " x509" error message... (And another one knew about
> this difference between the different build environments.)

If we make it optional and skip the relevant tests then there wouldn't be any
errors messages?  I do agree that all messaging around should be very clear
though, so it's obvious why tests were skipped.

Do you feel like expanding your patch or should I?

--
Daniel Gustafsson

  5. Re: "openssl" should not be optional

    Christoph Berg <myon@debian.org> — 2025-09-24T11:51:50Z

    Re: Daniel Gustafsson
> If we make it optional and skip the relevant tests then there wouldn't be any
> errors messages?

Or that, sure.

> Do you feel like expanding your patch or should I?

TBH I know very little about how TAP interfaces with the build system,
so that's better with you.

Thanks,
Christoph

  6. Re: "openssl" should not be optional

    Daniel Gustafsson <daniel@yesql.se> — 2025-09-24T13:57:46Z

    > On 24 Sep 2025, at 13:51, Christoph Berg <myon@debian.org> wrote:

>> Do you feel like expanding your patch or should I?
> 
> TBH I know very little about how TAP interfaces with the build system,
> so that's better with you.

Looking at this I was reminded that we already handle this by using a fallback
and the test worked all along.  The message for this was quite poorly worded
though, and used a warning instead of a note.  The attached will try to detect
openssl being missing before trying to run it, and will skip the warning
message if the fallback is used (which really isn't a warning in the first
place).

The ERROR in 003_sslinfo is intentional, we are testing that processing fails
by passing an invalid value.

--
Daniel Gustafsson

  7. Re: "openssl" should not be optional

    Christoph Berg <myon@debian.org> — 2025-09-24T15:13:44Z

    Re: Daniel Gustafsson
> Looking at this I was reminded that we already handle this by using a fallback
> and the test worked all along.  The message for this was quite poorly worded
> though, and used a warning instead of a note.  The attached will try to detect
> openssl being missing before trying to run it, and will skip the warning
> message if the fallback is used (which really isn't a warning in the first
> place).

Thanks, I just built the postgresql-18 again with this patch (and
openssl not installed [*]). It passes fine now.

In the meantime, I also got the report that postgresql-17 is not
failing in that environment, so the problem is new in 18.

> The ERROR in 003_sslinfo is intentional, we are testing that processing fails
> by passing an invalid value.

Ah, I was mentioning that in the original report because it only
showed up in the failing log, but that's just because the non-failing
build does not go scraping the test log files. That made the problem
look bigger than it actually was.

Thanks,
Christoph

[*] future builds will have openssl as build-dependency.

  8. Re: "openssl" should not be optional

    Daniel Gustafsson <daniel@yesql.se> — 2025-09-24T15:49:11Z

    > On 24 Sep 2025, at 17:13, Christoph Berg <myon@debian.org> wrote:
> 
> Re: Daniel Gustafsson
>> Looking at this I was reminded that we already handle this by using a fallback
>> and the test worked all along.  The message for this was quite poorly worded
>> though, and used a warning instead of a note.  The attached will try to detect
>> openssl being missing before trying to run it, and will skip the warning
>> message if the fallback is used (which really isn't a warning in the first
>> place).
> 
> Thanks, I just built the postgresql-18 again with this patch (and
> openssl not installed [*]). It passes fine now.
> 
> In the meantime, I also got the report that postgresql-17 is not
> failing in that environment, so the problem is new in 18.

That's odd, off the cuff I don't see anything materially different around this
but I'll do some more digging.  It will at least be fixed by 18.1.

--
Daniel Gustafsson

  9. Re: "openssl" should not be optional

    Christoph Berg <myon@debian.org> — 2025-09-24T17:27:39Z

    Re: Daniel Gustafsson
> > In the meantime, I also got the report that postgresql-17 is not
> > failing in that environment, so the problem is new in 18.
> 
> That's odd, off the cuff I don't see anything materially different around this
> but I'll do some more digging.  It will at least be fixed by 18.1.

Because I had already added openssl to 17's build-dependencies and
forgot to port that change to 18 *blush*:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1096243

Christoph