Skip to contentSkip to conversation

Fix implicit declarations when HAVE_OPENSSL_ENGINE is unset

PATCH In review Julien Muchembled 6 participants 21 messages Dec 16, 2016 – Jan 4, 2017

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Fix implicit declarations when HAVE_OPENSSL_ENGINE is unset

This fixes a regression in commit 8e95e20913:
on amd64, an implicit declaration of ERR_error_string leads to segfaults if the returned pointer does not fit in an 'int'.

Trac: #792

---
This patch is for the 2.3 branch. In the master branch, crypto_openssl.c already includes these files.

 src/openvpn/crypto_openssl.c | 2 ++
 1 file changed, 2 insertions(+)
src/openvpn/crypto_openssl.c +2 -0
index 7b1ac6c..fe22044 100644
@@ -45,6 +45,8 @@
 #include <openssl/objects.h>
 #include <openssl/evp.h>
 #include <openssl/des.h>
+#include <openssl/err.h>
+#include <openssl/rand.h>
 
 /*
  * Check for key size creepage.
Signature · 1 line
2.10.2.2.g19ca937.dirty
#1 lore raw

[Openvpn-devel] What about adding -Werror=implicit -Werror=format -Werror=format-security ?

To avoid issues like https://community.openvpn.net/openvpn/ticket/792 to happen again, I wanted to also submit a patch that adds a few -Werror= flags. However, I wonder what would be your preferred way to only add flags that are supported by the compiler.

One solution is with
https://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html
which means:
- copy ax_check_compile_flag.m4 from the autoconf archive to the openvpn repository
- include it in configure.ac
- and for example:

AX_CHECK_COMPILE_FLAG([ -Werror=implicit ], [
CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=implicit"
])

Julien

#2 lore raw

Re: [Openvpn-devel] What about adding -Werror=implicit -Werror=format -Werror=format-security ?

Quoted 9 lines · Julien Muchembled

To avoid issues like https://community.openvpn.net/openvpn/ticket/792 to happen again, I wanted to also submit a patch that adds a few -Werror= flags. However, I wonder what would be your preferred way to only add flags that are supported by the compiler.

One solution is with
https://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html
which means:
- copy ax_check_compile_flag.m4 from the autoconf archive to the openvpn repository
- include it in configure.ac
- and for example:

Quoted 3 lines

AX_CHECK_COMPILE_FLAG([ -Werror=implicit ], [
CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=implicit"
])

Yes, please!

You can put the macro in m4/

-Steffan

#3 lore raw

Re: [Openvpn-devel] What about adding -Werror=implicit -Werror=format -Werror=format-security ?

2016-12-16 22:06 GMT+05:00 Steffan Karger <[email protected]...>:

Quoted 6 lines · Julien Muchembled
Quoted 1 line

To avoid issues like https://community.openvpn.net/openvpn/ticket/792

to happen again, I wanted to also submit a patch that adds a few -Werror= flags. However, I wonder what would be your preferred way to only add flags that are supported by the compiler.

is it supported for clang ?

Quoted 30 lines
Quoted 3 lines

One solution is with
https://www.gnu.org/software/autoconf-archive/ax_check_

compile_flag.html

Quoted 2 lines

which means:
- copy ax_check_compile_flag.m4 from the autoconf archive to the openvpn

repository

Quoted 6 lines

- include it in configure.ac
- and for example:

AX_CHECK_COMPILE_FLAG([ -Werror=implicit ], [
CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=implicit"
])

Yes, please!

You can put the macro in m4/

-Steffan

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

#4 lore raw

Re: [Openvpn-devel] What about adding -Werror=implicit -Werror=format -Werror=format-security ?

Am 16.12.16 um 18:18 schrieb Илья Шипицин:

Quoted 14 lines

2016-12-16 22:06 GMT+05:00 Steffan Karger <[email protected]... <mailto:[email protected]...>>:

On 16-12-16 17:42, Julien Muchembled wrote:
> To avoid issues like https://community.openvpn.net/openvpn/ticket/792
<https://community.openvpn.net/openvpn/ticket/792> to happen again, I wanted to also submit a patch that adds a few -Werror= flags. However, I wonder what would be your preferred way to only add flags that are supported by the compiler.

Quoted 2 lines

is it supported for clang ?

Yes. (At least on my Mac)

Arne

#5 lore raw

PATCH 1/1 Build with a few -Werror= flags if the compiler supports them

In reply to Steffan Karger

The bug in Trac #792 (pointer wrongly truncated as 'int', leading to segfaults) would have been understood faster with either
-Werror=implicit or -Werror=format
(and above all, before running buggy executables in production)

Debian already compiles with -Werror=format-security, and it's indeed a good idea for a sensitive software like OpenVPN to use it.
---

Quoted 4 lines

Yes, please!

You can put the macro in m4/

OK. Not sure about the license. It's GPL3+
I also don't include the latest version, which has (among other changes):
-[AC_PREREQ(2.59)dnl for _AC_LANG_PREFIX
+[AC_PREREQ(2.64)dnl for _AC_LANG_PREFIX and AS_VAR_IF

configure.ac | 7 +++++

 m4/ax_check_compile_flag.m4 | 74 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 81 insertions(+)
 create mode 100644 m4/ax_check_compile_flag.m4
configure.ac +7 -0
index 4f086ea..3357ea0 100644
@@ -412,6 +412,13 @@ ifdef(
 	]
 )
 
+AX_CHECK_COMPILE_FLAG([ -Werror=implicit ], [
+    CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=implicit"
+])
+AX_CHECK_COMPILE_FLAG([ -Werror=format -Werror=format-security ], [
+    CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=format -Werror=format-security"
+])
+
 AC_C_CONST
 AC_C_INLINE
 AC_C_VOLATILE
m4/ax_check_compile_flag.m4 new file +74 -0

74 lines not on this page · raw message

Signature · 1 line
2.10.2.2.g19ca937.dirty
#6 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

Hi,

Quoted 8 lines · Julien Muchembled

The bug in Trac #792 (pointer wrongly truncated as 'int', leading to segfaults) would have been understood faster with either
-Werror=implicit or -Werror=format
(and above all, before running buggy executables in production)

Debian already compiles with -Werror=format-security, and it's indeed a good idea for a sensitive software like OpenVPN to use it.
---

Quoted 6 lines
Quoted 4 lines

Yes, please!

You can put the macro in m4/

OK. Not sure about the license. It's GPL3+

GPLv3 is fine as far as I'm aware, and the license is nicely contained in the file, so I think all is good.

Quoted 3 lines

I also don't include the latest version, which has (among other changes):
-[AC_PREREQ(2.59)dnl for _AC_LANG_PREFIX
+[AC_PREREQ(2.64)dnl for _AC_LANG_PREFIX and AS_VAR_IF

Good, 2.59 is reasonable, even RHEL6 has 2.63. Might be good if David or Gert gives this a test run on the build farm before applying though.

Quoted 10 lines

configure.ac | 7 +++++

 m4/ax_check_compile_flag.m4 | 74 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 81 insertions(+)
 create mode 100644 m4/ax_check_compile_flag.m4
configure.ac +0 -0
index 4f086ea..3357ea0 100644

configure.ac ifdef( · line 421

Quoted 10 lines
configure.ac +7 -0
@@ -412,6 +412,13 @@ ifdef(
 	]
 )
 
+AX_CHECK_COMPILE_FLAG([ -Werror=implicit ], [
+    CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=implicit"
+])
+AX_CHECK_COMPILE_FLAG([ -Werror=format -Werror=format-security ], [
+    CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=format -Werror=format-security"
+])
+

Shouldn't there be a CFLAGS="${CFLAGS} ${CFLAGS_EXTRA}" somewhere? Or just use CFLAGS directly, instead of _EXTRA. Without that, I don't see the flags appear in the make output.

-Steffan

#7 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

Quoted 11 lines · Steffan Karger

configure.ac ifdef( · line 421

Quoted 7 lines
configure.ac +7 -0
+AX_CHECK_COMPILE_FLAG([ -Werror=implicit ], [
+    CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=implicit"
+])
+AX_CHECK_COMPILE_FLAG([ -Werror=format -Werror=format-security ], [
+    CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=format -Werror=format-security"
+])
+

Shouldn't there be a CFLAGS="${CFLAGS} ${CFLAGS_EXTRA}" somewhere? Or just use CFLAGS directly, instead of _EXTRA. Without that, I don't see the flags appear in the make output.

(how did I miss that?) anyway, there's also
https://fossies.org/linux/alsa-lib/m4/attributes.m4

bigger, GPL2+, and it defines macros that simply append to CFLAGS (e.g. CC_CHECK_CFLAG_APPEND)

BTW, instead of failing on these 3 specific warnings, we could go the opposite way, since -Wall is quite silent. I suggest:

-Wall -Wno-unused -Wno-pointer-sign -Werror -Wno-error=strict-aliasing -Werror=format-security

Julien

#8 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

Quoted 16 lines · Julien Muchembled
Quoted 11 lines · Steffan Karger

configure.ac ifdef( · line 421

Quoted 7 lines
configure.ac +7 -0
+AX_CHECK_COMPILE_FLAG([ -Werror=implicit ], [
+    CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=implicit"
+])
+AX_CHECK_COMPILE_FLAG([ -Werror=format -Werror=format-security ], [
+    CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=format -Werror=format-security"
+])
+

Shouldn't there be a CFLAGS="${CFLAGS} ${CFLAGS_EXTRA}" somewhere? Or just use CFLAGS directly, instead of _EXTRA. Without that, I don't see the flags appear in the make output.

(how did I miss that?) anyway, there's also
https://fossies.org/linux/alsa-lib/m4/attributes.m4

Quoted 6 lines

bigger, GPL2+, and it defines macros that simply append to CFLAGS (e.g. CC_CHECK_CFLAG_APPEND)

BTW, instead of failing on these 3 specific warnings, we could go the opposite way, since -Wall is quite silent. I suggest:

-Wall -Wno-unused -Wno-pointer-sign -Werror -Wno-error=strict-aliasing -Werror=format-security

I like this, we could then get rid of the --enable-strict configure option. But I would want to test this in the master branch first to see what else we need. I for example also need:

-Wno-error=missing-braces, because clang still wrongfully warns about using = { 0 } to zero-initialize structs (fixed just recently in gcc)

-Wno-error=duplicate-decl-specifier, to be able to compile against pkcs11-helper

I reckon there will be more stuff that fails.

Also, is -Werror=format-security needed (instead of -Wformat-security) if we already have -Werror?

-Steffan

#9 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

Quoted 2 lines · Steffan Karger

Also, is -Werror=format-security needed (instead of -Wformat-security) if we already have -Werror?

No. In this case, it's indeed clearer to have -Wformat-security

Julien

#10 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

In reply to Julien Muchembled

Hi,

Quoted 3 lines · Julien Muchembled

BTW, instead of failing on these 3 specific warnings, we could go the opposite way, since -Wall is quite silent. I suggest:

-Wall -Wno-unused -Wno-pointer-sign -Werror -Wno-error=strict-aliasing -Werror=format-security

NAK to "-Wall -Werror", unless you've tested that this does not break compilation on any of the supported platforms.

The world is bigger than Linux.

gert

Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...
#11 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

Quoted 7 lines · Gert Doering
Quoted 3 lines · Julien Muchembled

BTW, instead of failing on these 3 specific warnings, we could go the opposite way, since -Wall is quite silent. I suggest:

-Wall -Wno-unused -Wno-pointer-sign -Werror -Wno-error=strict-aliasing -Werror=format-security

NAK to "-Wall -Werror", unless you've tested that this does not break compilation on any of the supported platforms.

Sure, but I think we should help out with that. Such as, do a test build on the supported platforms and see what fixes / extra flags we need to make it work. (I say we, because although I don't have access to the build systems, I am willing to help out with fixing fallout.)

I'm willing to invest in this, because I think using the compiler as a sanity checker more will save us time in the long run.

-Steffan

#12 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

Hi,

Quoted 10 lines · Steffan Karger
Quoted 2 lines

NAK to "-Wall -Werror", unless you've tested that this does not break compilation on any of the supported platforms.

Sure, but I think we should help out with that. Such as, do a test build on the supported platforms and see what fixes / extra flags we need to make it work. (I say we, because although I don't have access to the build systems, I am willing to help out with fixing fallout.)

I'm willing to invest in this, because I think using the compiler as a sanity checker more will save us time in the long run.

I'm not generally disagreeing to add -Werror, but then we might consider having either a --disable-strict setting, or something easily accessible to certain platforms to disable it.

Right now I'm somewhat concerned about Solaris, and very concerned about AIX - the latter is like a unix system built by people who have never seen one, and only had hearsay about POSIX standards. "Stuff does work", but the header files are always just slightly different, and unless you spend large amounts of time on special-case #ifdef TARGET_AIX, it's nearly impossible to get rid of all warnings.

So, having "first class ports" that build with -Wall -Werror, and "second class ports" that can opt-out (because it's too painful to the code base as a whole to fix these) would work for me...

Taking 2.4_rc2 and building on AIX with -Wall -Wno-pointer-sign is actually much less bad than I thought :-) - but there are things in there which are annoying, like these

../../../git/src/openvpn/route.c: In function 'add_route_ipv6':
../../../git/src/openvpn/route.c:1834:10: warning: variable 'gateway_needed' set but not used [-Wunused-but-set-variable]

     bool gateway_needed = false;
          ^

(fixing is easy, but implies adding an #ifdef TARGET_... orgy or refactoring this whole code part - which should be done, but won't happen "over night")

More problematic are these:

../../../git/src/openvpn/socket.c: In function 'print_link_socket_actual_ex':
../../../git/src/openvpn/socket.c:2802:21: warning: implicit declaration of function 'if_indextoname' [-Wimplicit-function-declaration]

                     if_indextoname(act->pi.in6.ipi6_ifindex, ifname);
                     ^
../../../git/src/openvpn/socket.c: In function 'unix_socket_get_peer_uid_gid':
../../../git/src/openvpn/socket.c:3950:5: warning: implicit declaration of function 'getpeereid' [-Wimplicit-function-declaration]
     if (getpeereid(sd, &u, &g) == -1)

../../../git/src/openvpn/tun.c: In function 'open_tun_generic':
../../../git/src/openvpn/tun.c:1787:13: warning: implicit declaration of function 'if_nametoindex' [-Wimplicit-function-declaration]
if (if_nametoindex( dev ) > 0)

... since we're really not supposed to redeclare system prototypes (and if we do, it will break on other versions of AIX).

-Werror is going to blow up in our faces if we do not fix ntlm.c first, anyway :-)

gert

Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...
#13 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

Quoted 4 lines · Gert Doering

Taking 2.4_rc2 and building on AIX with -Wall -Wno-pointer-sign is actually much less bad than I thought :-) - but there are things in there which are annoying, like these

Quoted 8 lines

../../../git/src/openvpn/route.c: In function 'add_route_ipv6':
../../../git/src/openvpn/route.c:1834:10: warning: variable 'gateway_needed' set but not used [-Wunused-but-set-variable]

     bool gateway_needed = false;
          ^

(fixing is easy, but implies adding an #ifdef TARGET_... orgy or refactoring this whole code part - which should be done, but won't happen "over night")

That's why I also suggested to have -Wno-unused, at least in a first time.
My idea was to avoid regression and detect issues easily on exotic configuration (openssl without crypto), not to change the code style in OpenVPN.

Quoted 10 lines

More problematic are these:

../../../git/src/openvpn/socket.c: In function 'print_link_socket_actual_ex':
../../../git/src/openvpn/socket.c:2802:21: warning: implicit declaration of function 'if_indextoname' [-Wimplicit-function-declaration]

                     if_indextoname(act->pi.in6.ipi6_ifindex, ifname);
                     ^
../../../git/src/openvpn/socket.c: In function 'unix_socket_get_peer_uid_gid':
../../../git/src/openvpn/socket.c:3950:5: warning: implicit declaration of function 'getpeereid' [-Wimplicit-function-declaration]
     if (getpeereid(sd, &u, &g) == -1)
Quoted 6 lines

../../../git/src/openvpn/tun.c: In function 'open_tun_generic':
../../../git/src/openvpn/tun.c:1787:13: warning: implicit declaration of function 'if_nametoindex' [-Wimplicit-function-declaration]
if (if_nametoindex( dev ) > 0)

... since we're really not supposed to redeclare system prototypes (and if we do, it will break on other versions of AIX).

:(
But we could detect such case during configure and add declarations if needed.

Julien

#14 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

In reply to Gert Doering

17 дек. 2016 г. 15:07 пользователь "Gert Doering" <[email protected]...> написал:

Hi,

Quoted 1 line · Julien Muchembled

BTW, instead of failing on these 3 specific warnings, we could go the

opposite way, since -Wall is quite silent. I suggest:

Quoted 2 lines

-Wall -Wno-unused -Wno-pointer-sign -Werror -Wno-error=strict-aliasing

-Werror=format-security

NAK to "-Wall -Werror", unless you've tested that this does not break compilation on any of the supported platforms.

The world is bigger than Linux.

There should be high level autoconf magic, which will add option if chosen compiler supports it.

I'm particurlarly afraid of cross compilers like mingw

gert

--
USENET is *not* the non-clickable part of WWW!

                                                           //

www.muc.de/~gert/
Gert Doering - Munich, Germany
[email protected]...
fax: +49-89-35655025 [email protected]...
muenchen.de

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

#15 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

Hi,

Quoted 4 lines · ???????? ??????????????
Quoted 1 line

The world is bigger than Linux.

There should be high level autoconf magic, which will add option if chosen compiler supports it.

That wasn't my point. Some systems are making it hard to get Linux-developed sources to compile without throwing warnings, or adding quite a bit of extra de-warnify-lines-of-code.

OpenVPN is not that bad in this regards, as we already take very much care about our code - but see my other mail regarding AIX.

Quoted 1 line

I'm particurlarly afraid of cross compilers like mingw

Yeah, and that one.

gert

Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...
#16 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

In reply to Julien Muchembled

Am 16.12.16 um 19:26 schrieb Julien Muchembled:

Quoted 8 lines

The bug in Trac #792 (pointer wrongly truncated as 'int', leading to segfaults) would have been understood faster with either
-Werror=implicit or -Werror=format
(and above all, before running buggy executables in production)

Debian already compiles with -Werror=format-security, and it's indeed a good idea for a sensitive software like OpenVPN to use it.
---

Quoted 6 lines
Quoted 4 lines

Yes, please!

You can put the macro in m4/

OK. Not sure about the license. It's GPL3+

We cannot accept GPL3+ since it is incompatible with our license (GPL2).

Arne

#17 lore raw

Re: [Openvpn-devel] [PATCH] Build with a few -Werror= flags if the compiler supports them

Quoted 9 lines · Arne Schwabe

Am 16.12.16 um 19:26 schrieb Julien Muchembled:

Quoted 8 lines

The bug in Trac #792 (pointer wrongly truncated as 'int', leading to segfaults) would have been understood faster with either
-Werror=implicit or -Werror=format
(and above all, before running buggy executables in production)

Debian already compiles with -Werror=format-security, and it's indeed a good idea for a sensitive software like OpenVPN to use it.
---

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines

Yes, please!

You can put the macro in m4/

OK. Not sure about the license. It's GPL3+

We cannot accept GPL3+ since it is incompatible with our license (GPL2).

Also for autoconf macro's that are not linked to our code at all?

-Steffan

#18 lore raw
In reply to Julien Muchembled
Quoted 20 lines · Julien Muchembled

This fixes a regression in commit 8e95e20913:
on amd64, an implicit declaration of ERR_error_string leads to segfaults if the returned pointer does not fit in an 'int'.

Trac: #792

---
This patch is for the 2.3 branch. In the master branch, crypto_openssl.c already includes these files.

 src/openvpn/crypto_openssl.c | 2 ++
 1 file changed, 2 insertions(+)
src/openvpn/crypto_openssl.c +0 -0
index 7b1ac6c..fe22044 100644

src/openvpn/crypto_openssl.c line 52

Quoted 8 lines
src/openvpn/crypto_openssl.c +2 -0
@@ -45,6 +45,8 @@
 #include <openssl/objects.h>
 #include <openssl/evp.h>
 #include <openssl/des.h>
+#include <openssl/err.h>
+#include <openssl/rand.h>
 
 /*
  * Check for key size creepage.

ACK, fix is clearly correct.

Though there must be more then just 'on amd64' to make this break - this code has run an a *lot* of amd64 systems and this is the first breakage report. (Of course that doesn't mean in any way that we shouldn't fix it, I'm just curious.)

-Steffan

#19 lore raw
Quoted 7 lines · Steffan Karger
Quoted 6 lines · Julien Muchembled

This fixes a regression in commit 8e95e20913:
on amd64, an implicit declaration of ERR_error_string leads to segfaults if the returned pointer does not fit in an 'int'.

Trac: #792

Quoted 8 lines
Quoted 1 line

[...]

ACK, fix is clearly correct.

Though there must be more then just 'on amd64' to make this break - this code has run an a *lot* of amd64 systems and this is the first breakage report. (Of course that doesn't mean in any way that we shouldn't fix it, I'm just curious.)

As written in the subject, when HAVE_OPENSSL_ENGINE is unset, which may be rare. Or for those who don't have, the pointer fits on 32 bits (probably the case if linked statically).

I wrote more on #792 about what happened to us. We do build SSL with crypto, but HAVE_OPENSSL_ENGINE was unset because of typos in the configure command.

Julien

#20 lore raw
In reply to Julien Muchembled

Sorry for the delay, this got lost in the pre-2.4 craziness.

Your patch has been applied to the release/2.3 branch.

Thanks!

commit ab1302d47b0f2b2ac9272b9fbb90ef0bd7b7cc35

Author: Julien Muchembled
Date:   Fri Dec 16 17:32:18 2016 +0100
     Fix implicit declarations when HAVE_OPENSSL_ENGINE is unset

     Signed-off-by: Julien Muchembled <[email protected]...>
     Acked-by: Steffan Karger <[email protected]...>
     Message-Id: <[email protected]...>
     URL: https://www.mail-archive.com/[email protected]/msg13591.html
     Signed-off-by: Gert Doering <[email protected]...>

--
kind regards,

Gert Doering