[Openvpn-devel] Getting rid of bundled lz4 ?

[Илья Шипицин]

Hello,

It was broadcasted several times that we will get rid of bundled lz4
someday.

Currently, windows installer is built using that lib. Does it make sense to
change windows installer?

Cheers,
Ilya Shipitsin
--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Do not assume that SSL_CTX_get/set_min/max_proto_version are macros

[Selva Nair]

Hi,

On Sun, Mar 4, 2018 at 6:22 PM, Steffan Karger  wrote:
>
> On 05-03-18 00:13, Jeremie Courreges-Anglas wrote:
>> On Sun, Mar 04 2018, Selva Nair  wrote:
>> --8<--
>> [...]. OpenSSL itself only provided said setters (since 2015)[2].  The
>>  getters were added to OpenSSL later (Sep 2017)[3].
>>
>> [2] 
>> https://github.com/openssl/openssl/commit/7946ab33cecce60afcc00afc8fc18f31f9e66bff
>> [3] 
>> https://github.com/openssl/openssl/commit/3edabd3ccb7aac89af5a63cfb2378e33a8be05d7
>> -->8--
>>
>> IIUC there are OpenSSL 1.1.0 releases out there that provide only the
>> setters, and that would also be affected by the requirement you propose.
>>
>> Github suggests that besides the master branch, the following tags have
>> the setters[2]:
>>
>> OpenSSL_1_1_1-pre2 OpenSSL_1_1_1-pre1 OpenSSL_1_1_0 OpenSSL_1_1_0g
>> OpenSSL_1_1_0f OpenSSL_1_1_0e OpenSSL_1_1_0d OpenSSL_1_1_0c
>> OpenSSL_1_1_0b OpenSSL_1_1_0a OpenSSL_1_1_0-pre6 OpenSSL_1_1_0-pre5
>> OpenSSL_1_1_0-pre4 OpenSSL_1_1_0-pre3 OpenSSL_1_1_0-pre2
>>
>> while support for getters[3] is only in:
>>
>> OpenSSL_1_1_1-pre2 OpenSSL_1_1_1-pre1
>
> That commit was cherry-picked to the OpenSSL_1_1_0-stable branch, and is
> available int 1.1.0g+:
> https://github.com/openssl/openssl/commit/af51a74ade8bbab5ed49a3560dcb70d89896dc29
>
> But yeah, that's still something we might need to think about.

Yes this is troubling. I had tested Windows build using 1.1.0g, but
our release is built with 1.1.0f. So, for example, --tls-version-min
1.2 will not get read back as 1.2. Most likely it'll only lead to less
than ideal UX in some corner cases (e.g. the error check min <= max in
cryptoapi.c will not work as expected).

Selva

--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Add --tls-cert-profile option for mbedtls builds

[Steffan Karger]

On 05-03-18 00:26, Steffan Karger wrote:
> Yes, I'd rather not use the workaround if not needed.

Bad wording.  Read that as "I'm no longer opposed to a patch".

-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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Add --tls-cert-profile option for mbedtls builds

[Steffan Karger]

Hi,

On 04-03-18 19:59, Jeremie Courreges-Anglas wrote:
> On Thu, Dec 14 2017, Steffan Karger  wrote:
> 
> [...]
> 
>> NAK.
>>
>> Looking at this patch again I realize I have misunderstood the
>> intentions when first looking at it.  I thought LibreSSL *did* have an
>> SSL_CTX_get0_certificate() and this patch would make us use it (instead
>> of the workaround in the #else).  But this is just about replacing the
>> version check with a configure check.
> 
> Are you still opposed to such a diff (updated version attached), now
> that LibreSSL HEAD provides SSL_CTX_get0_certificate?

Yes, I'd rather not use the workaround if not needed.  Still not very
happy about the approach though.  Why not simply add || LIBRESSL_VERSION
> x.y.z ?

>> I oppose that change because it
>> hides information I want to have:  "what code can be purged when we drop
>> support for openssl 1.0 and libressl?".
> 
> Maybe there's another way to encode that information?  Like,
> consistently formatted comments describing the first OpenSSL (and
> LibreSSL) releases that provided a function?

Yes, we could do that.  But if we're going to put that info into the
code anyway, why not just use the define?

-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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Do not assume that SSL_CTX_get/set_min/max_proto_version are macros

[Steffan Karger]

On 05-03-18 00:13, Jeremie Courreges-Anglas wrote:
> On Sun, Mar 04 2018, Selva Nair  wrote:
> --8<--
> [...]. OpenSSL itself only provided said setters (since 2015)[2].  The
>  getters were added to OpenSSL later (Sep 2017)[3].
> 
> [2] 
> https://github.com/openssl/openssl/commit/7946ab33cecce60afcc00afc8fc18f31f9e66bff
> [3] 
> https://github.com/openssl/openssl/commit/3edabd3ccb7aac89af5a63cfb2378e33a8be05d7
> -->8--
> 
> IIUC there are OpenSSL 1.1.0 releases out there that provide only the
> setters, and that would also be affected by the requirement you propose.
> 
> Github suggests that besides the master branch, the following tags have
> the setters[2]:
> 
> OpenSSL_1_1_1-pre2 OpenSSL_1_1_1-pre1 OpenSSL_1_1_0 OpenSSL_1_1_0g
> OpenSSL_1_1_0f OpenSSL_1_1_0e OpenSSL_1_1_0d OpenSSL_1_1_0c
> OpenSSL_1_1_0b OpenSSL_1_1_0a OpenSSL_1_1_0-pre6 OpenSSL_1_1_0-pre5
> OpenSSL_1_1_0-pre4 OpenSSL_1_1_0-pre3 OpenSSL_1_1_0-pre2
> 
> while support for getters[3] is only in:
> 
> OpenSSL_1_1_1-pre2 OpenSSL_1_1_1-pre1

That commit was cherry-picked to the OpenSSL_1_1_0-stable branch, and is
available int 1.1.0g+:
https://github.com/openssl/openssl/commit/af51a74ade8bbab5ed49a3560dcb70d89896dc29

But yeah, that's still something we might need to think about.

-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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

[Steffan Karger]

On 04-03-18 23:23, Jeremie Courreges-Anglas wrote:
> On Sun, Mar 04 2018, Selva Nair  wrote:
>> Libressl developers break API compatibility with openssl in such
>> perverse ways that there are no easy ways to support it. Take, for
>> example, the patch I just sent out which checks for certain functions
>> instead of disabling using LIBRESSL_VERSION_NUMBER. It finds two "set"
>> functions defined in libressl but two related "get" ones are not
>> found. So the compat layer will get used for those. But there is no
>> guarantee that such mixed usage leads to logically correct code. In
>> fact, the compat layer functions for min/max proto-version are not the
>> same as those in openssl 1.1. Those are a work around meant for
>> cleanly handling multiple versions of openssl without using ifdefs all
>> over the code. If libressl has implemented those set functions as in
>> openssl 1.1, then those get functions from compat layer would not be
>> what you should be using, but that's what you will get.
> 
> I'd like to add more details here.
> 
> At the time LibreSSL added the setters (May 2017)[1], OpenSSL itself
> only provided said setters (since 2015)[2].  The getters were added to
> OpenSSL later (Sep 2017)[3].
> 
> [1] 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl.h.diff?r1=1.127=1.128
> [2] 
> https://github.com/openssl/openssl/commit/7946ab33cecce60afcc00afc8fc18f31f9e66bff
> [3] 
> https://github.com/openssl/openssl/commit/3edabd3ccb7aac89af5a63cfb2378e33a8be05d7
> 
> So I don't think the current situation can be summed up as a plain
> oversight or bad design choice.

Which is exactly why using OPENSSL_VERSION to determine the available
API would be so much cleaner.  No horribly slow configure checks and
easier to maintain code.

LibreSSL made the design choice to deviate from the OpenSSL API and put
lies into OPENSSL_VERSION, and then expects products that support
openssl to deal with the mess.  Yes, I think that's a bad design choice.
 But that's not the point - I guess every project makes bad choices
every now and then.  As soon as our official support warning is merged,
I'm fine with continuing the current practice of accepting patches to
keep LibreSSL working as long as they don't pollute the code.  If
LibreSSL is moving towards implementing the parts of the OpenSSL 1.1 API
we need, that hopefully will be just a few small patches.

If they then also set their OPENSSL_VERSION to match the API version
they are trying to support, I'd not have much left to complain about ;-)

-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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

[Steffan Karger]

Hi,

Most has been said, so I won't reiterate that.  Gert++, Selva++.

On 04-03-18 13:43, Mina Barret via Openvpn-devel wrote:
> Ok, bummer, the (german) wikipedia experience again - rejected. The
> second and third read of the well distributed Changelog(s) and release
> note(s) does not bring up a 'We do no longer support LibreSSL' note. The
> sourcecode contains ifdefs that already take care about LibreSSL.

Exactly this is the reason why I've been reluctant to accept LibreSSL
patches in the past.  It might give people the idea that we ever
supported it.  We never claimed to support LibreSSL.  Even more, we've
broadcasted more than once [0,1,2] that we do *not* support libressl.

But I can't really blame you for assuming we did.  We can't expect
everyone to follow the mailing list.  In hindsight, we should have
immediately added a patch like I recently submitted, to leave no doubt
about the state of our LibreSSL support.  (Though I'd also like to
defend ourselves a bit, LibreSSL lured us into this mess by pretending
to be OpenSSL-compatible.)

> Steffan Karger: When the introduced block
> in 0e8a30c0b05c1e2b59a1dea0a6eab5daa1d9d9a1 really is 'not really
> needed', can we add a additional ifdef arround it to make it build
> with libressl?

This block is needed if the linked crypto lib does not support the API
we expect, namely the OpenSSL 1.1 API.  If LibreSSL claims to implement
the OpenSSL API, they should do so.  I don't have time to figure out how
they subtly broke the build this week.  (Yes, I think OpenSSL's choice
to use macro's is bad design.  But that is the API we do support.)

-Steffan

[0]
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg09221.html

[1]
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg11272.html

[2]
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15295.html

--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

[Jeremie Courreges-Anglas]

On Sun, Mar 04 2018, Selva Nair  wrote:

[...]

> Libressl developers break API compatibility with openssl in such
> perverse ways that there are no easy ways to support it. Take, for
> example, the patch I just sent out which checks for certain functions
> instead of disabling using LIBRESSL_VERSION_NUMBER. It finds two "set"
> functions defined in libressl but two related "get" ones are not
> found. So the compat layer will get used for those. But there is no
> guarantee that such mixed usage leads to logically correct code. In
> fact, the compat layer functions for min/max proto-version are not the
> same as those in openssl 1.1. Those are a work around meant for
> cleanly handling multiple versions of openssl without using ifdefs all
> over the code. If libressl has implemented those set functions as in
> openssl 1.1, then those get functions from compat layer would not be
> what you should be using, but that's what you will get.

I'd like to add more details here.

At the time LibreSSL added the setters (May 2017)[1], OpenSSL itself
only provided said setters (since 2015)[2].  The getters were added to
OpenSSL later (Sep 2017)[3].

[1] 
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl.h.diff?r1=1.127=1.128
[2] 
https://github.com/openssl/openssl/commit/7946ab33cecce60afcc00afc8fc18f31f9e66bff
[3] 
https://github.com/openssl/openssl/commit/3edabd3ccb7aac89af5a63cfb2378e33a8be05d7

So I don't think the current situation can be summed up as a plain
oversight or bad design choice.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


signature.asc
Description: PGP signature
--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Do not assume that SSL_CTX_get/set_min/max_proto_version are macros

[Selva Nair]

Hi,

On Sun, Mar 4, 2018 at 1:48 PM, Jeremie Courreges-Anglas  
wrote:
> On Sun, Mar 04 2018, selva.n...@gmail.com wrote:
>> From: Selva Nair 
>>
>> Openssl docs do not explicitly state these to be macros although they
>> are currently defined as such.
>
> Actually they are documented as macros by OpenSSL since day 1, see
> NOTES.

You are right, I missed that in the docs. In that case my patch is not
needed especially so if libressl will provide those macros.

I'm still concerned about set and get functions coming from different
sources and may be we should fix that by requiring that if set is
defined we need get too. But that will once again break libressl
compatibility.

Selva

--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Add --tls-cert-profile option for mbedtls builds

[Jeremie Courreges-Anglas]

On Thu, Dec 14 2017, Steffan Karger  wrote:

[...]

> NAK.
>
> Looking at this patch again I realize I have misunderstood the
> intentions when first looking at it.  I thought LibreSSL *did* have an
> SSL_CTX_get0_certificate() and this patch would make us use it (instead
> of the workaround in the #else).  But this is just about replacing the
> version check with a configure check.

Are you still opposed to such a diff (updated version attached), now
that LibreSSL HEAD provides SSL_CTX_get0_certificate?

> I oppose that change because it
> hides information I want to have:  "what code can be purged when we drop
> support for openssl 1.0 and libressl?".

Maybe there's another way to encode that information?  Like,
consistently formatted comments describing the first OpenSSL (and
LibreSSL) releases that provided a function?

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
From e6d80207bf7f1323670d0bc1102fa51309b1aa14 Mon Sep 17 00:00:00 2001
From: Jeremie Courreges-Anglas 
Date: Sun, 4 Mar 2018 19:24:36 +0100
Subject: [PATCH] Detect availability of SSL_CTX_get0_certificate

instead of relying on simpler version checks.  This allows using
SSL_CTX_get0_certificate with LibreSSL.
---
 configure.ac  | 1 +
 src/openvpn/ssl_openssl.c | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 626b4dd4..e4525b09 100644
--- a/configure.ac
+++ b/configure.ac
@@ -918,6 +918,7 @@ if test "${with_crypto_library}" = "openssl"; then
 			EVP_MD_CTX_new \
 			EVP_MD_CTX_free \
 			EVP_MD_CTX_reset \
+			SSL_CTX_get0_certificate \
 			SSL_CTX_get_default_passwd_cb \
 			SSL_CTX_get_default_passwd_cb_userdata \
 			SSL_CTX_set_security_level \
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index 8ef68ebd..19580312 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -459,8 +459,8 @@ tls_ctx_check_cert_time(const struct tls_root_ctx *ctx)
 
 ASSERT(ctx);
 
-#if OPENSSL_VERSION_NUMBER >= 0x10002000L && !defined(LIBRESSL_VERSION_NUMBER)
-/* OpenSSL 1.0.2 and up */
+#ifdef HAVE_SSL_CTX_GET0_CERTIFICATE
+/* OpenSSL 1.0.2 and up, LibreSSL 2.7.0 and up */
 cert = SSL_CTX_get0_certificate(ctx->ctx);
 #else
 /* OpenSSL 1.0.1 and earlier need an SSL object to get at the certificate */
@@ -494,7 +494,7 @@ tls_ctx_check_cert_time(const struct tls_root_ctx *ctx)
 }
 
 cleanup:
-#if OPENSSL_VERSION_NUMBER < 0x10002000L || defined(LIBRESSL_VERSION_NUMBER)
+#ifndef HAVE_SSL_CTX_GET0_CERTIFICATE
 SSL_free(ssl);
 #endif
 return;
-- 
2.16.0



signature.asc
Description: PGP signature
--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

[Selva Nair]

Hi,

On Sun, Mar 4, 2018 at 11:47 AM, Jeremie Courreges-Anglas
 wrote:
> On Sun, Mar 04 2018, Gert Doering  wrote:
>
> [...]
>
>> "Please note that LibreSSL is not a supported crypto backend. We
>>  accept patches and we do test on OpenBSD 6.0 which comes with
>>  LibreSSL, but if newer versions of LibreSSL break API compatibility
>>  we do not take responsibility to fix that."
>>
>>
>> I think a patch adding these LIBRESSL_VERSION checks has a reasonable
>> chance of being ACKed and merged :-) - but LibreSSL support stuff has
>> to come from some who cares, so Steffan or Antonio are not going to
>> go out and check patches for "will it break LibreSSL?"...
>
> I don't think adding "&& !defined(LIBRESSL_VERSION_NUMBER)" in more
> places would be a good idea.  Those checks would do more harm than good
> in the long run, preventing the use of new interfaces when they get
> implemented by LibreSSL.  Better use function availability checks IMHO.

Libressl developers break API compatibility with openssl in such
perverse ways that there are no easy ways to support it. Take, for
example, the patch I just sent out which checks for certain functions
instead of disabling using LIBRESSL_VERSION_NUMBER. It finds two "set"
functions defined in libressl but two related "get" ones are not
found. So the compat layer will get used for those. But there is no
guarantee that such mixed usage leads to logically correct code. In
fact, the compat layer functions for min/max proto-version are not the
same as those in openssl 1.1. Those are a work around meant for
cleanly handling multiple versions of openssl without using ifdefs all
over the code. If libressl has implemented those set functions as in
openssl 1.1, then those get functions from compat layer would not be
what you should be using, but that's what you will get.

So IMO, it may be more worthwhile for those invested in libressl to
convince the developers to make more sane decisions. Either they want
libressl to be a better openssl or a different crypto library. They
can't behave as neither and both at the same time and expect
users/developers to work around their personal opinions of what
openssl should be.

Selva

--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Do not assume that SSL_CTX_get/set_min/max_proto_version are macros

[Jeremie Courreges-Anglas]

On Sun, Mar 04 2018, selva.n...@gmail.com wrote:
> From: Selva Nair 
>
> Openssl docs do not explicitly state these to be macros although they
> are currently defined as such.

Actually they are documented as macros by OpenSSL since day 1, see
NOTES.

> Use AC_CHECK_DECLS to test for these so that
> both function and macro forms could be detected.

Looks like the right way to handle such a situation.
Your diff looks good, and works for me against LibreSSL HEAD on
OpenBSD-current:

checking whether SSL_CTX_get_min_proto_version is declared... no
checking whether SSL_CTX_get_max_proto_version is declared... no
checking whether SSL_CTX_set_min_proto_version is declared... yes
checking whether SSL_CTX_set_max_proto_version is declared... yes

PASS: t_lpback.sh
The following test will take about two minutes.
If the addresses are in use, this test will retry up to two times.
PASS: t_cltsrv.sh

All 2 tests passed
(1 test was not run)


> Signed-off-by: Selva Nair 
> ---
> Though not meant as a fixup for libressl, as a side effect
> this also makes 2.4.5 build with newer libressl versions.
> (built on freebsd 11 using libressl 2.6.4 while testing patch 238)
> Notes: (i) libressl defines only the set functions and neither
> are macros. So get functions will get used from the compat layer.

More notes, possibly relevant:
- LibreSSL implement those as functions to provide better type checking.
  IIUC this is inspired by the same choice done in BoringSSL.
- yesterday I added macros for compatibility in LibreSSL HEAD, see
  https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl.h
  This should land in LibreSSL 2.7.0.
- adding the getters part is planned

>  configure.ac | 12 
>  src/openvpn/openssl_compat.h |  8 
>  2 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 626b4dd..2a8e87f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -948,6 +948,18 @@ if test "${with_crypto_library}" = "openssl"; then
>   EC_GROUP_order_bits
>   ]
>   )
> + AC_CHECK_DECLS(
> + [
> + SSL_CTX_get_min_proto_version,
> + SSL_CTX_get_max_proto_version,
> + SSL_CTX_set_min_proto_version,
> + SSL_CTX_set_max_proto_version,
> + ],
> + ,
> + ,
> + [[#include ]]
> +
> + )
>  
>   CFLAGS="${saved_CFLAGS}"
>   LIBS="${saved_LIBS}"
> diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h
> index d375fab..340d452 100644
> --- a/src/openvpn/openssl_compat.h
> +++ b/src/openvpn/openssl_compat.h
> @@ -661,7 +661,7 @@ EC_GROUP_order_bits(const EC_GROUP *group)
>  #define RSA_F_RSA_OSSL_PRIVATE_ENCRYPT   RSA_F_RSA_EAY_PRIVATE_ENCRYPT
>  #endif
>  
> -#ifndef SSL_CTX_get_min_proto_version
> +#if !HAVE_DECL_SSL_CTX_GET_MIN_PROTO_VERSION
>  /** Return the min SSL protocol version currently enabled in the context.
>   *  If no valid version >= TLS1.0 is found, return 0. */
>  static inline int
> @@ -684,7 +684,7 @@ SSL_CTX_get_min_proto_version(SSL_CTX *ctx)
>  }
>  #endif /* SSL_CTX_get_min_proto_version */
>  
> -#ifndef SSL_CTX_get_max_proto_version
> +#if !HAVE_DECL_SSL_CTX_GET_MAX_PROTO_VERSION
>  /** Return the max SSL protocol version currently enabled in the context.
>   *  If no valid version >= TLS1.0 is found, return 0. */
>  static inline int
> @@ -707,7 +707,7 @@ SSL_CTX_get_max_proto_version(SSL_CTX *ctx)
>  }
>  #endif /* SSL_CTX_get_max_proto_version */
>  
> -#ifndef SSL_CTX_set_min_proto_version
> +#if !HAVE_DECL_SSL_CTX_SET_MIN_PROTO_VERSION
>  /** Mimics SSL_CTX_set_min_proto_version for OpenSSL < 1.1 */
>  static inline int
>  SSL_CTX_set_min_proto_version(SSL_CTX *ctx, long tls_ver_min)
> @@ -736,7 +736,7 @@ SSL_CTX_set_min_proto_version(SSL_CTX *ctx, long 
> tls_ver_min)
>  }
>  #endif /* SSL_CTX_set_min_proto_version */
>  
> -#ifndef SSL_CTX_set_max_proto_version
> +#if !HAVE_DECL_SSL_CTX_SET_MAX_PROTO_VERSION
>  /** Mimics SSL_CTX_set_max_proto_version for OpenSSL < 1.1 */
>  static inline int
>  SSL_CTX_set_max_proto_version(SSL_CTX *ctx, long tls_ver_max)

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


signature.asc
Description: PGP signature
--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Do not assume that SSL_CTX_get/set_min/max_proto_version are macros

[Mina Barret via Openvpn-devel]

Great, Thank You!



--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Do not assume that SSL_CTX_get/set_min/max_proto_version are macros

[selva . nair]

From: Selva Nair 

Openssl docs do not explicitly state these to be macros although they
are currently defined as such. Use AC_CHECK_DECLS to test for these so that
both function and macro forms could be detected.

Signed-off-by: Selva Nair 
---
Though not meant as a fixup for libressl, as a side effect
this also makes 2.4.5 build with newer libressl versions.
(built on freebsd 11 using libressl 2.6.4 while testing patch 238)
Notes: (i) libressl defines only the set functions and neither
are macros. So get functions will get used from the compat layer.

 configure.ac | 12 
 src/openvpn/openssl_compat.h |  8 
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 626b4dd..2a8e87f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -948,6 +948,18 @@ if test "${with_crypto_library}" = "openssl"; then
EC_GROUP_order_bits
]
)
+   AC_CHECK_DECLS(
+   [
+   SSL_CTX_get_min_proto_version,
+   SSL_CTX_get_max_proto_version,
+   SSL_CTX_set_min_proto_version,
+   SSL_CTX_set_max_proto_version,
+   ],
+   ,
+   ,
+   [[#include ]]
+
+   )
 
CFLAGS="${saved_CFLAGS}"
LIBS="${saved_LIBS}"
diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h
index d375fab..340d452 100644
--- a/src/openvpn/openssl_compat.h
+++ b/src/openvpn/openssl_compat.h
@@ -661,7 +661,7 @@ EC_GROUP_order_bits(const EC_GROUP *group)
 #define RSA_F_RSA_OSSL_PRIVATE_ENCRYPT   RSA_F_RSA_EAY_PRIVATE_ENCRYPT
 #endif
 
-#ifndef SSL_CTX_get_min_proto_version
+#if !HAVE_DECL_SSL_CTX_GET_MIN_PROTO_VERSION
 /** Return the min SSL protocol version currently enabled in the context.
  *  If no valid version >= TLS1.0 is found, return 0. */
 static inline int
@@ -684,7 +684,7 @@ SSL_CTX_get_min_proto_version(SSL_CTX *ctx)
 }
 #endif /* SSL_CTX_get_min_proto_version */
 
-#ifndef SSL_CTX_get_max_proto_version
+#if !HAVE_DECL_SSL_CTX_GET_MAX_PROTO_VERSION
 /** Return the max SSL protocol version currently enabled in the context.
  *  If no valid version >= TLS1.0 is found, return 0. */
 static inline int
@@ -707,7 +707,7 @@ SSL_CTX_get_max_proto_version(SSL_CTX *ctx)
 }
 #endif /* SSL_CTX_get_max_proto_version */
 
-#ifndef SSL_CTX_set_min_proto_version
+#if !HAVE_DECL_SSL_CTX_SET_MIN_PROTO_VERSION
 /** Mimics SSL_CTX_set_min_proto_version for OpenSSL < 1.1 */
 static inline int
 SSL_CTX_set_min_proto_version(SSL_CTX *ctx, long tls_ver_min)
@@ -736,7 +736,7 @@ SSL_CTX_set_min_proto_version(SSL_CTX *ctx, long 
tls_ver_min)
 }
 #endif /* SSL_CTX_set_min_proto_version */
 
-#ifndef SSL_CTX_set_max_proto_version
+#if !HAVE_DECL_SSL_CTX_SET_MAX_PROTO_VERSION
 /** Mimics SSL_CTX_set_max_proto_version for OpenSSL < 1.1 */
 static inline int
 SSL_CTX_set_max_proto_version(SSL_CTX *ctx, long tls_ver_max)
-- 
2.1.4


--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

[Jeremie Courreges-Anglas]

On Sun, Mar 04 2018, Gert Doering  wrote:

[...]

> "Please note that LibreSSL is not a supported crypto backend. We
>  accept patches and we do test on OpenBSD 6.0 which comes with
>  LibreSSL, but if newer versions of LibreSSL break API compatibility
>  we do not take responsibility to fix that."
>
>
> I think a patch adding these LIBRESSL_VERSION checks has a reasonable
> chance of being ACKed and merged :-) - but LibreSSL support stuff has
> to come from some who cares, so Steffan or Antonio are not going to
> go out and check patches for "will it break LibreSSL?"...

I don't think adding "&& !defined(LIBRESSL_VERSION_NUMBER)" in more
places would be a good idea.  Those checks would do more harm than good
in the long run, preventing the use of new interfaces when they get
implemented by LibreSSL.  Better use function availability checks IMHO.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


signature.asc
Description: PGP signature
--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Add a warning that we do not officially support LibreSSL

[Jeremie Courreges-Anglas]

On Sun, Mar 04 2018, Steffan Karger  wrote:
> Hi,
>
> On 04-03-18 10:08, Gert Doering wrote:
>> On Thu, Mar 01, 2018 at 12:11:23AM +0100, Steffan Karger wrote:
>>> As discussed in the community meeting of 13-12-2017, we should warn our
>>> users that LibreSSL is not officially supported.  We expect that it
>>> currently works, but it might suddenly break or we might decide to no
>>> longer build against LibreSSL in the future.
>> 
>> Generally speaking, I agree.
>> 
>> Should we also add a warning (+ sleep 60 to be extra-annoying?) to
>> configure if LibreSSL is detected?
>
> I considered that (modulo the sleep 60) and wrote the code to do the
> configure check, but then thought that a not-suppressible warning in the
> logs would be sufficient.  I still think it is, but don't mind re-adding
> it to configure.ac if you prefer that.

As an OpenBSD developer and the maintainer of our OpenVPN port,
I certainly care about building and using OpenVPN with LibreSSL.
I have already provided patches in the past, and yesterday I pushed
compat glue in LibreSSL so that openvpn-2.4.5 can build on OpenBSD
(-current).

So I'm wondering what would be needed to consider LibreSSL "supported".

I hear that there are concerns over LibreSSL not being API-compatible
with OpenSSL.  As you may have noticed, LibreSSL recently introduced
lots of OpenSSL-1.1+ interfaces.  While there is no plan to support the
full OpenSSL-1.1 API (tons of functions were added, not all of them seem
useful...), the intent is to provide what the ecosystem actually needs.
I can probably serve as a bridge between the two projects here.

If you see other points where I - or anyone else - can help, please
share. :)

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


signature.asc
Description: PGP signature
--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

[Gert Doering]

Hi,

On Sun, Mar 04, 2018 at 07:43:14AM -0500, Mina Barret via Openvpn-devel wrote:
> The release last week was different than the releases before.
> Usually all i have to do is updating the version, rebuild and QA.
> The release notes state 'This is primarily a maintenance release,
> with further improved OpenSSL 1.1'. To my surprise the build-openvpn
> repository now uses the OpenSSL 1.1 dependency, but why should
> OpenSSL 1.0 no longer work right?

1.0 should work fine - most of the buildbots are on some version of 
openssl 1.0.x.  Windows builds were changed to 1.1 to get access to
the latest and greatest features (TLS 1.2 with cryptoapi, I think?)

It seems we broke 0.9.8 compilation by missing two #ifdef - this is an
issue we need to fix - our current buildbot farm uses the same settings 
for 2.4 and "master" testing, so pointing to an openssl version that is
no longer supported for "master" (to get the 2.4 testing) will break 
things.  Dedicated test setups for "2.4 with 0.9.8" are needed.


Which 1.0 version did we break?  1.0.0, 1.0.1 and 1.0.2 are quite 
different from what I can read in our commit logs - maybe it's the same
issue that broke 0.9.8 that also broke 1.0.0 (both are EOLed, but 
our goal is to never intentionally break a working dependency in the
middle of a release train).

> It does not, and this is fine as it's reaching EOL soon anyway.
> And maybe it is not breaking the OpenVPN API so its ok to increase
> only the last version digit. This adds more patch to my openvpn-build
> repository as now the 2.3.18 version _needs_ openssl 1.0 and cannot
> use 1.1 while 2.4.5 needs openssl 1.1 and does no longer build with
> 1.0 - but thats my problem i guess.

As I said, the aim was to have 2.4.5 build with the same libraries (exact
versions) that 2.4.4 worked with.   So 1.0. should be fine, but
there's large differences in the  here...

If we broke something that we say we support, please let us know which 
versions, and whether the already committed patch for 2.4 for older 
openssl versions (88abb911ea22a30) already fixes your problems as well.


> After the OpenSSL switch worked with 2.3.18 and 2.4.5, LibreSSL
> had one compile error - not what i experienced in the last years
> but ok, I can patch, and i have a system for patches anyway (eg for
> xor). To save other people the trouble - as long as they build the
> unmodified source - I'd like to contribute to your project with a
> simple pull request, one that makes the latest OpenVPN version work
> with the latest LibreSSL. Maybe you just do not build it this way,
> but soon others may run into this. In the end its not more than a
> typo/broken link on wikipedia.

This particular LibreSSL breakage is even more annoying than "normal" - 
we do test on OpenBSD 6.0 with the LibreSSL version on that system, and
it seems a *newer* LibreSSL version added API functions that they did
not have previously, adding them as a function where OpenSSL uses 
a macro.  This sort of API differences (while still defining an 
OPENSSL_VERSION that claims "of course we have all the cool stuff!")
is what annoys our crypto developers enough that they considered to
drop LibreSSL support completely... 

Since we do want OpenBSD support, we compromised on "we're not going
to intentionally break it, but if *they* break it, we're not going to
chase their changes to see what we have to do now".


[..]
> Ok, bummer, the (german) wikipedia experience again - rejected.
> The second and third read of the well distributed Changelog(s) and
> release note(s) does not bring up a 'We do no longer support LibreSSL'
> note. The sourcecode contains ifdefs that already take care about
> LibreSSL. There are recent patches that handle mbedSSL, so you must
> be interested in supporting other crypto libraries. Do i really
> have to write a email to the developer that made the last LibreSSL
> patch, bribe her or him with *hugs* or *backrubs* (sorry!) to get
> the simplest possible patch into upstream? What do i have to do
> then to get more complex stuff approved? Weekly meetings?

Well, first of all, the fact that we do not accept PRs is very well
documented *in* the PR form.  Github does not let us turn off PRs
completely, otherwise we'd have done that long ago - but we put
documentation in there to state this quite clearly.

Github is not our primary working platform.  We push there, to have
resiliency (and to sf.net and to gitlab) but our workflow is "incoming
mail with patches goes to the list, it gets reviewed, ACKed on the list 
[= archived], then merged".

The ChangeLog I was referring to can be found here:

https://openvpn.net/index.php/open-source/downloads.html

"Please note that LibreSSL is not a supported crypto backend. We
 accept patches and we do test on OpenBSD 6.0 which comes with
 LibreSSL, but if newer versions of LibreSSL break API compatibility
 we do not take responsibility to fix that."


I think a patch adding these LIBRESSL_VERSION checks has a reasonable

[Openvpn-devel] [PATCH] Improve management-external-key/cert error handling

[Steffan Karger]

Check the return values of management_query_cert() and
tls_ctx_use_external_private_key(), and error out with a more descriptive
error message.  To do so, we make the openssl-backed implementation of
tls_ctx_use_external_private_key() not throw fatal error anymore.

(And fix line wrapping while touching this code.)

Signed-off-by: Steffan Karger 
---
 src/openvpn/ssl.c | 29 +
 src/openvpn/ssl_openssl.c |  2 +-
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 79b985e..25a7085 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -660,18 +660,31 @@ init_ssl(const struct options *options, struct 
tls_root_ctx *new_ctx)
 else if ((options->management_flags & MF_EXTERNAL_KEY)
  && (options->cert_file || options->management_flags & 
MF_EXTERNAL_CERT))
 {
-if (options->cert_file)
+if (options->cert_file
+&& 0 != tls_ctx_use_external_private_key(new_ctx,
+ options->cert_file,
+ 
options->cert_file_inline))
 {
-tls_ctx_use_external_private_key(new_ctx, options->cert_file,
- options->cert_file_inline);
+msg(M_WARN, "Failed to initialize management-external-key");
+goto err;
 }
 else
 {
-char *external_certificate = management_query_cert(management,
-   
options->management_certificate);
-tls_ctx_use_external_private_key(new_ctx, external_certificate,
- true);
-free(external_certificate);
+char *external_cert = management_query_cert(
+management, options->management_certificate);
+
+if (!external_cert)
+{
+msg(M_FATAL, "Failed to initialize management-external-cert");
+}
+
+if (0 != tls_ctx_use_external_private_key(new_ctx, external_cert,
+  true))
+{
+msg(M_FATAL, "Failed to initialize management-external-key");
+}
+
+free(external_cert);
 }
 }
 #endif
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index 66d98c5..87f6768 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -1327,7 +1327,7 @@ tls_ctx_use_external_private_key(struct tls_root_ctx *ctx,
 return 0;
 
 err:
-crypto_msg(M_FATAL, "Cannot enable SSL external private key capability");
+crypto_msg(M_WARN, "Cannot enable SSL external private key capability");
 return 1;
 }
 
-- 
2.7.4


--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] LibreSSL support in OpenVPN 2.4.5

[Mina Barret via Openvpn-devel]

Hallo OpenVPN developers,

The last years i closely follow your advances in the source. When you release a 
new version of the software, i will pull it, build it in different 
configurations and ship it to a small userbase.
To allow the users to choose the flavor of SSL, one of the configurations is 
'-libressl' and the other is '-openssl'. Personally i do not care, as they 
should do the same thing - encrypt and decrypt byte arrays with advanced 
mathematics - but there are situations and preferences where having a different 
library can be handy.

In order to have the builds reproducible, i maintain a private fork of 
openvpn/openvpn-build that adds support for libressl (and pulls all 
dependencies with https and always uses the very latest openssl 1.0 
patchlevel). This repository is used to build the openvpn executables for 
archlinux, debian, fedora, ubuntu, osx and windows in appropriate VM's.

The release last week was different than the releases before. Usually all i 
have to do is updating the version, rebuild and QA. The release notes state 
'This is primarily a maintenance release, with further improved OpenSSL 1.1'. 
To my surprise the build-openvpn repository now uses the OpenSSL 1.1 
dependency, but why should OpenSSL 1.0 no longer work right?

It does not, and this is fine as it's reaching EOL soon anyway. And maybe it is 
not breaking the OpenVPN API so its ok to increase only the last version digit. 
This adds more patch to my openvpn-build repository as now the 2.3.18 version 
_needs_ openssl 1.0 and cannot use 1.1 while 2.4.5 needs openssl 1.1 and does 
no longer build with 1.0 - but thats my problem i guess.

After the OpenSSL switch worked with 2.3.18 and 2.4.5, LibreSSL had one compile 
error - not what i experienced in the last years but ok, I can patch, and i 
have a system for patches anyway (eg for xor). To save other people the trouble 
- as long as they build the unmodified source - I'd like to contribute to your 
project with a simple pull request, one that makes the latest OpenVPN version 
work with the latest LibreSSL. Maybe you just do not build it this way, but 
soon others may run into this. In the end its not more than a typo/broken link 
on wikipedia.
I research other patches that 'fix LibreSSL' (not many) to make the change as 
close as possible to your accepted standards.
I research the patch that causes the build error and evaluate if my change may 
have any drawbacks.
I setup a GH identity to fork, apply the patch, push and create a Pull request, 
just to learn, that this is not the 'right' way.

Then i get the response "See the release notes for 2.4.5." and "if LibreSSL is 
then breaking the API
again, the active developers very much do not care."

Ok, bummer, the (german) wikipedia experience again - rejected. The second and 
third read of the well distributed Changelog(s) and release note(s) does not 
bring up a 'We do no longer support LibreSSL' note. The sourcecode contains 
ifdefs that already take care about LibreSSL. There are recent patches that 
handle mbedSSL, so you must be interested in supporting other crypto libraries. 
Do i really have to write a email to the developer that made the last LibreSSL 
patch, bribe her or him with *hugs* or *backrubs* (sorry!) to get the simplest 
possible patch into upstream? What do i have to do then to get more complex 
stuff approved? Weekly meetings?

Last try with the mailinglist, maybe someone copies the lines into the next 
release so i can drop the patch, I do not want attribution, I do not want to 
write emotional messages on a mailing list, nor do i want to have responses to 
them. I want to interact technically using a pull request for a issue i see.

Gert Doering: thanks for the quick response on GH
Steffan Karger: When the introduced block in 
0e8a30c0b05c1e2b59a1dea0a6eab5daa1d9d9a1 really is 'not really needed', can we 
add a additional ifdef arround it to make it build with libressl?

Everyone reading: Sorry for the rant, thank you for the latest release and the 
great work and have a nice sunday!

https://github.com/OpenVPN/openvpn/pull/102--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Make return code external tls key match docs

[Gert Doering]

Your patch has been applied to the master and release/2.4 branch
(with some conflicts due to changed context in master, but that was
easy enough to resolve).

Thanks.

commit 6bee1a1fc01f3d3ddf114b48e52e5b10d57033cb (master)
commit 1f342aad6a13aaae1cc54f632498e0646a1bfe1a (release/2.4)
Author: Joost Rijneveld
Date:   Wed Feb 28 14:52:40 2018 +0100

 Make return code external tls key match docs

 Acked-by: Gert Doering 
 Message-Id: <20180228135240.22945-1-jo...@joostrijneveld.nl>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16577.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] Check for time_t overflow in event_timeout_trigger()

[Steffan Karger]

Hi,

On 01-03-18 05:15, Selva Nair wrote:
> We can avoid all overflow and eliminate the check and the ASSERT
> by writing it as
> 
> time_t wakeup = (et->last - local_now) + et->n; // parens added for clarity
> 
> For the first subtraction to overflow, last and now have to differ by
>> INT_MAX (for 32 bit time_t), not something we should worry about
> (can't happen in normal operation).
> Further, the term in brackets is always negative (as now >= last),
> while et->n is positive and < INT_MAX by construction. So the final
> addition also cannot overflow. All assuming that 32 bit "now" and
> "last" are not used beyond 2037.
> 
> That would take care of this particular overflow concern.

Looking more closely at the "now" handling, I see that it indeed can not
go back (our notion of time can, but that is managed through now_adj,
not by setting now back).

So your approach is much simpler and better.  Since that is your
solution, do mind sending a patch?  I'll then do the review-and-ack.

-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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Make return code external tls key match docs

[Steffan Karger]

Hi,

On 28-02-18 14:52, Joost Rijneveld wrote:
> In tls_ctx_use_external_private_key, the return codes were inverted
> compared to what is documented in ssl_backend.h (and what can
> reasonably be expected). Internally the return code is never checked,
> so this did not directly result in any change of behavior.
> ---
>  src/openvpn/ssl_mbedtls.c | 6 +++---
>  src/openvpn/ssl_openssl.c | 4 ++--
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
> index 3906cd55..8e31980a 100644
> --- a/src/openvpn/ssl_mbedtls.c
> +++ b/src/openvpn/ssl_mbedtls.c
> @@ -630,7 +630,7 @@ tls_ctx_use_external_private_key(struct tls_root_ctx *ctx,
>  
>  if (ctx->crt_chain == NULL)
>  {
> -return 0;
> +return 1;
>  }
>  
>  ALLOC_OBJ_CLEAR(ctx->external_key, struct external_context);
> @@ -640,10 +640,10 @@ tls_ctx_use_external_private_key(struct tls_root_ctx 
> *ctx,
>  if (!mbed_ok(mbedtls_pk_setup_rsa_alt(ctx->priv_key, ctx->external_key,
>NULL, external_pkcs1_sign, 
> external_key_len)))
>  {
> -return 0;
> +return 1;
>  }
>  
> -return 1;
> +return 0;
>  }
>  #endif /* ifdef MANAGMENT_EXTERNAL_KEY */
>  
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index d91458b0..8ef68ebd 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -1327,11 +1327,11 @@ tls_ctx_use_external_private_key(struct tls_root_ctx 
> *ctx,
>  goto err;
>  }
>  #endif /* OPENSSL_VERSION_NUMBER > 1.1.0 dev */
> -return 1;
> +return 0;
>  
>  err:
>  crypto_msg(M_FATAL, "Cannot enable SSL external private key capability");
> -return 0;
> +return 1;
>  }
>  
>  #endif /* ifdef MANAGMENT_EXTERNAL_KEY */
> 

Thanks for the patch, and pointing out this inconsistency.  Changes make
sense and make this function follow what seems to be the default pattern
in the surrounding code.

Acked-by: Steffan Karger 

(What bothers me more is that we don't actually check the return values,
but I'll send a follow-up patch to fix that.)

-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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Add a warning that we do not officially support LibreSSL

[Steffan Karger]

Hi,

On 04-03-18 10:08, Gert Doering wrote:
> On Thu, Mar 01, 2018 at 12:11:23AM +0100, Steffan Karger wrote:
>> As discussed in the community meeting of 13-12-2017, we should warn our
>> users that LibreSSL is not officially supported.  We expect that it
>> currently works, but it might suddenly break or we might decide to no
>> longer build against LibreSSL in the future.
> 
> Generally speaking, I agree.
> 
> Should we also add a warning (+ sleep 60 to be extra-annoying?) to
> configure if LibreSSL is detected?

I considered that (modulo the sleep 60) and wrote the code to do the
configure check, but then thought that a not-suppressible warning in the
logs would be sufficient.  I still think it is, but don't mind re-adding
it to configure.ac if you prefer that.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Add a warning that we do not officially support LibreSSL

[Gert Doering]

Hi,

On Thu, Mar 01, 2018 at 12:11:23AM +0100, Steffan Karger wrote:
> As discussed in the community meeting of 13-12-2017, we should warn our
> users that LibreSSL is not officially supported.  We expect that it
> currently works, but it might suddenly break or we might decide to no
> longer build against LibreSSL in the future.

Generally speaking, I agree.

Should we also add a warning (+ sleep 60 to be extra-annoying?) to
configure if LibreSSL is detected?

gert
-- 
now what should I write here...

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Add missing #ifdef SSL_OP_NO_TLSv1_1/2

[Gert Doering]

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

(I've added a commit message explaining what Selva wrote about the
cherrypick etc., setting you as author)

commit 88abb911ea22a306e87fba58410da45c2baad57f
Author: Simon Matter
Date:   Fri Mar 2 08:49:31 2018 +0100

 Add missing #ifdef SSL_OP_NO_TLSv1_1/2

 Signed-off-by: Gert Doering 
 Acked-by: Selva Nair 
 Message-Id: 
<52e860ea74ac958309368374049f14bd.squir...@webmail.bi.invoca.ch>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16588.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Delete the IPv6 route to the connected network on tun close

[Gert Doering]

Acked-by: Gert Doering 

Test compiled, not actually run - but "stare at code" is convincing enough.

Your patch has been applied to the master and release/2.4 branch.

commit b607900ba937b5f45796d2e3810ef91a32826927 (master)
commit 716fdb24be7857e242c3174a51485446502481ea (release/2.4)
Author: Selva Nair
Date:   Thu Mar 1 15:34:44 2018 -0500

 Delete the IPv6 route to the connected network on tun close

 Signed-off-by: Selva Nair 
 Acked-by: Gert Doering 
 Message-Id: <1519936484-26102-1-git-send-email-selva.n...@gmail.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16598.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Trac tickets

[Antonio Quartulli]

On 04/03/18 16:05, Samuli Seppänen wrote:
> The owner would get a notification email but the ticket would not be
> automatically assigned to him/her.
> 
> Thoughts?

I like that. Because we mostly need "somebody responsible for that area"
to be notified and it does not necessarily need to be the owner of the
specific ticket.

Cheers,

-- 
Antonio Quartulli



signature.asc
Description: OpenPGP digital signature
--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Trac tickets

[Samuli Seppänen]

Il 03/03/2018 17:58, Selva Nair ha scritto:
> Hi,
> 
> These days many (all?) trac tickets appears with an owner set. When I
> see an owner it gives the impression that person is looking into it
> and makes me less inclined to investigate.
> 
> But it looks like this is automatically assigned and in many cases the
> so-called owner is MIA. It only gives a wrong impression that the
> ticket is being handled.
> 
> Selva
> 

I see you point. I think a better approach would be to automatically CC
the owner of the "component" (e.g. crypto, packaging):

https://trac-hacks.org/wiki/DefaultCcPlugin

The owner would get a notification email but the ticket would not be
automatically assigned to him/her.

Thoughts?

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel