--- gvpe/configure.ac	2016/11/02 07:06:38	1.65
+++ gvpe/configure.ac	2018/10/25 04:32:26	1.66
@@ -4,7 +4,7 @@
 AC_INIT
 AC_CONFIG_SRCDIR([src/gvpe.C])
 AC_CANONICAL_TARGET
-AM_INIT_AUTOMAKE(gvpe, 3.0)
+AM_INIT_AUTOMAKE(gvpe, 3.1)
 AC_CONFIG_HEADERS([config.h])
 AM_MAINTAINER_MODE
 
@@ -236,11 +236,7 @@
 dnl These are defined in files in m4/
 tinc_TUNTAP
 
-tinc_OPENSSL
-if test "x$openssl_include" != x; then
-   CXXFLAGS="$CXXFLAGS -I$openssl_include"
-fi
-dnl tinc_ZLIB
+PKG_CHECK_MODULES([LIBCRYPTO], [libcrypto >= 1])
 
 AC_ARG_ENABLE(threads,
   [AS_HELP_STRING(--enable-threads,try to use threads for long-running asynchronous operations (default enabled).)],
@@ -451,4 +447,37 @@
 echo "***"
 echo
 
+if pkg-config --exists 'libcrypto >= 1.1 libcrypto < 2.0'; then
+   cat <<EOF
+@<:@33m
+***
+*** WARNING WARNING WARNING WARNING WARNING WARNING WARNING
+***
+*** You seem to configure gvpe with OpenSSL 1.1 or newer.
+*** While this probably compiles, please note that this is not only
+*** unsupported, but also discouraged.
+***
+*** It is recommended to use either OpenSSL 1.0, as long as that is still
+*** supported, or LibreSSL (https://www.libressl.org/).
+***
+*** This is not a political issue - while porting GVPE to the newer
+*** OpenSSL 1.1 API, I encountered two incompatible API changes that were
+*** not documented, were not caught while compiling but caused security
+*** issues. When reported, the reaction of the OpenSSL developers was to
+*** update the documentation.
+***
+*** As a result, I lost all confidence in the ability and desire of
+*** OpenSSL developers to create a safe API, and would highly recommend
+*** switching to LibreSSL which explicitly avoids such braking changes.
+***
+*** WARNING WARNING WARNING WARNING WARNING WARNING WARNING
+***
+*** Again, do not use OpenSSL 1.1 and complain if stuff breaks.
+*** You have been warned, but your choice is respected.
+***
+@<:@0m
+
+EOF
+fi
+