Make finding openssl program a configure or meson option
Various test suites use the "openssl" program as part of their setup.
There isn't a way to override which openssl program is to be used, other
than by fiddling with the path, perhaps. This has gotten increasingly
problematic with some of the work I have been doing, because different
versions of openssl have different capabilities and do different things
by default. This patch checks for an openssl binary in configure and
meson setup, with appropriate ways to override it. This is similar to
how "lz4" and "zstd" are handled, for example. The meson build system
actually already did this, but the result was only used in some places.
This is now applied more uniformly.
Attachments:
0001-Make-finding-openssl-program-a-configure-or-meson-op.patchtext/plain; charset=UTF-8; name=0001-Make-finding-openssl-program-a-configure-or-meson-op.patchDownload+96-29
On Tue, Oct 11, 2022 at 05:06:22PM +0200, Peter Eisentraut wrote:
Various test suites use the "openssl" program as part of their setup. There
isn't a way to override which openssl program is to be used, other than by
fiddling with the path, perhaps. This has gotten increasingly problematic
with some of the work I have been doing, because different versions of
openssl have different capabilities and do different things by default.
This patch checks for an openssl binary in configure and meson setup, with
appropriate ways to override it. This is similar to how "lz4" and "zstd"
are handled, for example. The meson build system actually already did this,
but the result was only used in some places. This is now applied more
uniformly.
openssl-env allows the use of the environment variable of the same
name. This reminds me a bit of the recent interferences with GZIP,
for example.
This patch is missing one addition of set_single_env() in
vcregress.pl, and one update of install-windows.sgml where all the
supported environment variables for commands are listed.
--
Michael
On 12.10.22 03:08, Michael Paquier wrote:
On Tue, Oct 11, 2022 at 05:06:22PM +0200, Peter Eisentraut wrote:
Various test suites use the "openssl" program as part of their setup. There
isn't a way to override which openssl program is to be used, other than by
fiddling with the path, perhaps. This has gotten increasingly problematic
with some of the work I have been doing, because different versions of
openssl have different capabilities and do different things by default.
This patch checks for an openssl binary in configure and meson setup, with
appropriate ways to override it. This is similar to how "lz4" and "zstd"
are handled, for example. The meson build system actually already did this,
but the result was only used in some places. This is now applied more
uniformly.openssl-env allows the use of the environment variable of the same
name. This reminds me a bit of the recent interferences with GZIP,
for example.
Sorry, what is "openssl-env"? I can't find that anywhere.
This patch is missing one addition of set_single_env() in
vcregress.pl, and one update of install-windows.sgml where all the
supported environment variables for commands are listed.
Ok, I'll add that.
On 12.10.22 03:08, Michael Paquier wrote:
On Tue, Oct 11, 2022 at 05:06:22PM +0200, Peter Eisentraut wrote:
Various test suites use the "openssl" program as part of their setup. There
isn't a way to override which openssl program is to be used, other than by
fiddling with the path, perhaps. This has gotten increasingly problematic
with some of the work I have been doing, because different versions of
openssl have different capabilities and do different things by default.
This patch checks for an openssl binary in configure and meson setup, with
appropriate ways to override it. This is similar to how "lz4" and "zstd"
are handled, for example. The meson build system actually already did this,
but the result was only used in some places. This is now applied more
uniformly.openssl-env allows the use of the environment variable of the same
name. This reminds me a bit of the recent interferences with GZIP,
for example.
Okay, I see what you meant here now. openssl-env is the man page
describing environment variables used by OpenSSL. I don't see any
conflicts with what is being proposed here.
This patch is missing one addition of set_single_env() in
vcregress.pl, and one update of install-windows.sgml where all the
supported environment variables for commands are listed.
Added. New patch attached.
Attachments:
v2-0001-Make-finding-openssl-program-a-configure-or-meson.patchtext/plain; charset=UTF-8; name=v2-0001-Make-finding-openssl-program-a-configure-or-meson.patchDownload+106-29
On Tue, Oct 18, 2022 at 06:46:53PM +0200, Peter Eisentraut wrote:
On 12.10.22 03:08, Michael Paquier wrote:
openssl-env allows the use of the environment variable of the same
name. This reminds me a bit of the recent interferences with GZIP,
for example.Okay, I see what you meant here now. openssl-env is the man page describing
environment variables used by OpenSSL.
Yeah, sorry. That's what I was referring to.
I don't see any conflicts with what is being proposed here.
Its meaning is the same in the context of the OpenSSL code. LibreSSL
has nothing of the kind.
Added. New patch attached.
Looks fine as a whole, except for one nit.
src/test/ssl/t/001_ssltests.pl: warn 'couldn\'t run `openssl x509` to get client cert serialno';
Perhaps this warning should mentioned $ENV{OPENSSL} instead?
--
Michael
On 19.10.22 05:06, Michael Paquier wrote:
Looks fine as a whole, except for one nit.
src/test/ssl/t/001_ssltests.pl: warn 'couldn\'t run `openssl x509` to get client cert serialno';
Perhaps this warning should mentioned $ENV{OPENSSL} instead?
Committed with that change.