Show version of OpenSSL in ./configure output
Hi all,
5e4dacb9878c has reminded me that we don't show the version of OpenSSL
in the output of ./configure. This would be useful to know when
looking at issues within the buildfarm, and I've wanted that a few
times.
How about the attached to use the openssl command, if available, to
display this information? Libraries may be installed while the
command is not available, but in most cases I'd like to think that it
is around, and it is less complex than using something like
SSLeay_version() from libcrypto.
meson already shows this information, so no additions are required
there. Also, LibreSSL uses `openssl`, right?
Thoughts or comments?
--
Michael
Attachments:
openssl-configure.patchtext/x-diff; charset=us-asciiDownload
diff --git a/configure b/configure
index c2cb1b1b24..6cb0310fb3 100755
--- a/configure
+++ b/configure
@@ -648,13 +648,13 @@ MSGFMT
PG_CRC32C_OBJS
CFLAGS_CRC
LIBOBJS
-OPENSSL
ZSTD
LZ4
UUID_LIBS
LDAP_LIBS_BE
LDAP_LIBS_FE
with_ssl
+OPENSSL
PTHREAD_CFLAGS
PTHREAD_LIBS
PTHREAD_CC
@@ -904,6 +904,7 @@ LDFLAGS_EX
LDFLAGS_SL
PERL
PYTHON
+OPENSSL
MSGFMT
TCLSH'
@@ -1615,6 +1616,7 @@ Some influential environment variables:
LDFLAGS_SL extra linker flags for linking shared libraries only
PERL Perl program
PYTHON Python program
+ OPENSSL path to openssl command
MSGFMT msgfmt program for NLS
TCLSH Tcl interpreter program (tclsh)
@@ -12863,6 +12865,65 @@ else
fi
fi
+ # Print version of OpenSSL, if command is available.
+
+ if test -z "$OPENSSL"; then
+ for ac_prog in openssl
+do
+ # Extract the first word of "$ac_prog", so it can be a program name with args.
+set dummy $ac_prog; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_path_OPENSSL+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ case $OPENSSL in
+ [\\/]* | ?:[\\/]*)
+ ac_cv_path_OPENSSL="$OPENSSL" # Let the user override the test with a path.
+ ;;
+ *)
+ as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+ IFS=$as_save_IFS
+ test -z "$as_dir" && as_dir=.
+ for ac_exec_ext in '' $ac_executable_extensions; do
+ if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ ac_cv_path_OPENSSL="$as_dir/$ac_word$ac_exec_ext"
+ $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+ break 2
+ fi
+done
+ done
+IFS=$as_save_IFS
+
+ ;;
+esac
+fi
+OPENSSL=$ac_cv_path_OPENSSL
+if test -n "$OPENSSL"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $OPENSSL" >&5
+$as_echo "$OPENSSL" >&6; }
+else
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+ test -n "$OPENSSL" && break
+done
+
+else
+ # Report the value of OPENSSL in configure's output in all cases.
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for OPENSSL" >&5
+$as_echo_n "checking for OPENSSL... " >&6; }
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $OPENSSL" >&5
+$as_echo "$OPENSSL" >&6; }
+fi
+
+ pgac_openssl_version="$($OPENSSL version 2> /dev/null || echo no)"
+ { $as_echo "$as_me:${as_lineno-$LINENO}: using openssl $pgac_openssl_version" >&5
+$as_echo "$as_me: using openssl $pgac_openssl_version" >&6;}
# Function introduced in OpenSSL 1.0.2, not in LibreSSL.
for ac_func in SSL_CTX_set_cert_cb
do :
diff --git a/configure.ac b/configure.ac
index 440b08d113..35585df598 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1360,6 +1360,11 @@ if test "$with_ssl" = openssl ; then
AC_SEARCH_LIBS(CRYPTO_new_ex_data, [eay32 crypto], [], [AC_MSG_ERROR([library 'eay32' or 'crypto' is required for OpenSSL])])
AC_SEARCH_LIBS(SSL_new, [ssleay32 ssl], [], [AC_MSG_ERROR([library 'ssleay32' or 'ssl' is required for OpenSSL])])
fi
+ # Print version of OpenSSL, if command is available.
+ AC_ARG_VAR(OPENSSL, [path to openssl command])
+ PGAC_PATH_PROGS(OPENSSL, openssl)
+ pgac_openssl_version="$($OPENSSL version 2> /dev/null || echo no)"
+ AC_MSG_NOTICE([using openssl $pgac_openssl_version])
# Function introduced in OpenSSL 1.0.2, not in LibreSSL.
AC_CHECK_FUNCS([SSL_CTX_set_cert_cb])
# Functions introduced in OpenSSL 1.1.0. We used to check for
Michael Paquier <michael@paquier.xyz> writes:
5e4dacb9878c has reminded me that we don't show the version of OpenSSL
in the output of ./configure. This would be useful to know when
looking at issues within the buildfarm, and I've wanted that a few
times.
+1, I've wished for that too. It's not 100% clear that whatever
openssl is in your PATH matches the libraries we select, but this
will get it right in most cases and it seems like about the right
level of effort.
+ pgac_openssl_version="$($OPENSSL version 2> /dev/null || echo no)"
Maybe "echo 'openssl not found'" would be better.
regards, tom lane
On Sun, Oct 22, 2023 at 08:34:40PM -0400, Tom Lane wrote:
+1, I've wished for that too. It's not 100% clear that whatever
openssl is in your PATH matches the libraries we select, but this
will get it right in most cases and it seems like about the right
level of effort.
Yes, I don't reallt want to add more macros for the sake of this
information.
+ pgac_openssl_version="$($OPENSSL version 2> /dev/null || echo no)"
Maybe "echo 'openssl not found'" would be better.
Sure.
--
Michael
On 23.10.23 02:26, Michael Paquier wrote:
5e4dacb9878c has reminded me that we don't show the version of OpenSSL
in the output of ./configure. This would be useful to know when
looking at issues within the buildfarm, and I've wanted that a few
times.How about the attached to use the openssl command, if available, to
display this information? Libraries may be installed while the
command is not available, but in most cases I'd like to think that it
is around, and it is less complex than using something like
SSLeay_version() from libcrypto.meson already shows this information, so no additions are required
there. Also, LibreSSL uses `openssl`, right?
The problem is that the binary might not match the library, so this
could be very misleading. Also, meson gets the version via pkg-config,
so the result would also be inconsistent with meson. I am afraid this
approach would be unreliable in the really interesting cases.
+ # Print version of OpenSSL, if command is available. + AC_ARG_VAR(OPENSSL, [path to openssl command]) + PGAC_PATH_PROGS(OPENSSL, openssl)
There is already a call like this in configure.ac, so (if this approach
is taken) you should rearrange things to make use of that one.
Show quoted text
+ pgac_openssl_version="$($OPENSSL version 2> /dev/null || echo no)" + AC_MSG_NOTICE([using openssl $pgac_openssl_version])
On 23 Oct 2023, at 08:22, Peter Eisentraut <peter@eisentraut.org> wrote:
On 23.10.23 02:26, Michael Paquier wrote:
5e4dacb9878c has reminded me that we don't show the version of OpenSSL
in the output of ./configure. This would be useful to know when
looking at issues within the buildfarm, and I've wanted that a few
times.
Many +1's, this has been on my TODO for some time but has never bubbled to the
top. Thanks for working on this.
How about the attached to use the openssl command, if available, to
display this information? Libraries may be installed while the
command is not available, but in most cases I'd like to think that it
is around, and it is less complex than using something like
SSLeay_version() from libcrypto.
meson already shows this information, so no additions are required
there. Also, LibreSSL uses `openssl`, right?The problem is that the binary might not match the library, so this could be very misleading. Also, meson gets the version via pkg-config, so the result would also be inconsistent with meson. I am afraid this approach would be unreliable in the really interesting cases.
I tend to agree with this, it would be preferrable to be consistent with meson
if possible/feasible.
--
Daniel Gustafsson
Daniel Gustafsson <daniel@yesql.se> writes:
On 23 Oct 2023, at 08:22, Peter Eisentraut <peter@eisentraut.org> wrote:
The problem is that the binary might not match the library, so this could be very misleading. Also, meson gets the version via pkg-config, so the result would also be inconsistent with meson. I am afraid this approach would be unreliable in the really interesting cases.
I tend to agree with this, it would be preferrable to be consistent with meson
if possible/feasible.
The configure script doesn't use pkg-config to find OpenSSL, so that
would also risk a misleading result. I'm inclined to guess that
believing "openssl version" would be less likely to give a wrong
answer than believing "pkg-config --modversion openssl". The former
amounts to assuming that your PATH is consistent with whatever you
set as the include and library search paths. The latter, well,
hasn't got any principle at all, because we aren't consulting
pkg-config for this.
Also, since "PGAC_PATH_PROGS(OPENSSL, openssl)" prints the full path
to what it found, you can at least tell after the fact that you
are being misled, because you can cross-check that path against
the -L switches being used for libraries. I don't think there's
any equivalent sanity check available for what pkg-config tells us,
if we're not consulting that for the library location.
meson.build may be fine here --- I suppose the reason that gets
the version via pkg-config is that it also gets other build details
from there. It's slightly worrisome that the autoconf and meson
build systems might choose different openssl installations, but
that's possibly true of lots of our dependencies.
Another angle worth considering is that "openssl version" provides
more information. On my RHEL8 box:
$ pkg-config --modversion openssl
1.1.1k
$ openssl version
OpenSSL 1.1.1k FIPS 25 Mar 2021
On my laptop using MacPorts:
$ pkg-config --modversion openssl
3.1.3
$ openssl version
OpenSSL 3.1.3 19 Sep 2023 (Library: OpenSSL 3.1.3 19 Sep 2023)
regards, tom lane
On 23.10.23 16:26, Tom Lane wrote:
Also, since "PGAC_PATH_PROGS(OPENSSL, openssl)" prints the full path to
what it found, you can at least tell after the fact that you are being
misled, because you can cross-check that path against the -L switches
being used for libraries.
Yeah, that seems ok.
On 23 Oct 2023, at 18:06, Peter Eisentraut <peter@eisentraut.org> wrote:
On 23.10.23 16:26, Tom Lane wrote:
Also, since "PGAC_PATH_PROGS(OPENSSL, openssl)" prints the full path to what it found, you can at least tell after the fact that you are being misled, because you can cross-check that path against the -L switches being used for libraries.
Yeah, that seems ok.
+1, all good points raised, thanks!
--
Daniel Gustafsson
On Mon, Oct 23, 2023 at 06:06:02PM +0200, Peter Eisentraut wrote:
On 23.10.23 16:26, Tom Lane wrote:
Also, since "PGAC_PATH_PROGS(OPENSSL, openssl)" prints the full path to
what it found, you can at least tell after the fact that you are being
misled, because you can cross-check that path against the -L switches
being used for libraries.Yeah, that seems ok.
FWIW, I was also contemplating this one yesterday:
+PKG_CHECK_MODULES(OPENSSL, openssl)
Still, when I link my builds to a custom OpenSSL one, I force PATH to
point to a command of openssl related to the libs used so
PGAC_PATH_PROGS is more useful. I guess that everybody here does the
same. It could be of course possible to show both the command from
PATH and from pkg-config, but that's just confusing IMO.
There may be a point in doing the same for other commands like LZ4 and
Zstandard but these have been less of a pain in the buildfarm, even if
we don't use them for that long, so I cannot get excited about
spending more ./configure cycles for these.
Please find attached a patch to move the version call close to the
existing PGAC_PATH_PROGS. And of course, I'd like to do a backpatch.
Is that OK?
--
Michael
Attachments:
openssl-configure-v2.patchtext/x-diff; charset=us-asciiDownload
diff --git a/configure b/configure
index c2cb1b1b24..cfd968235f 100755
--- a/configure
+++ b/configure
@@ -14077,6 +14077,9 @@ $as_echo_n "checking for OPENSSL... " >&6; }
$as_echo "$OPENSSL" >&6; }
fi
+pgac_openssl_version="$($OPENSSL version 2> /dev/null || echo openssl not found)"
+{ $as_echo "$as_me:${as_lineno-$LINENO}: using openssl: $pgac_openssl_version" >&5
+$as_echo "$as_me: using openssl: $pgac_openssl_version" >&6;}
if test "$with_ssl" = openssl ; then
ac_fn_c_check_header_mongrel "$LINENO" "openssl/ssl.h" "ac_cv_header_openssl_ssl_h" "$ac_includes_default"
if test "x$ac_cv_header_openssl_ssl_h" = xyes; then :
diff --git a/configure.ac b/configure.ac
index 440b08d113..f220b379b3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1553,6 +1553,8 @@ if test "$with_gssapi" = yes ; then
fi
PGAC_PATH_PROGS(OPENSSL, openssl)
+pgac_openssl_version="$($OPENSSL version 2> /dev/null || echo openssl not found)"
+AC_MSG_NOTICE([using openssl: $pgac_openssl_version])
if test "$with_ssl" = openssl ; then
AC_CHECK_HEADER(openssl/ssl.h, [], [AC_MSG_ERROR([header file <openssl/ssl.h> is required for OpenSSL])])
AC_CHECK_HEADER(openssl/err.h, [], [AC_MSG_ERROR([header file <openssl/err.h> is required for OpenSSL])])
Michael Paquier <michael@paquier.xyz> writes:
Please find attached a patch to move the version call close to the
existing PGAC_PATH_PROGS. And of course, I'd like to do a backpatch.
Is that OK?
OK by me.
regards, tom lane