Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-17 Thread Илья Шипицин
2017-02-17 23:17 GMT+05:00 Илья Шипицин : > > Пт, 17 февр. 2017 г. в 22:21, David Sommerseth topphemmelig.net>: > >> On 17/02/17 17:35, Emmanuel Deloget wrote: >> > >> > Now, I have a question which is related to this. The way I'm doing >> > things, I

Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-17 Thread David Sommerseth
On 17/02/17 22:59, Emmanuel Deloget wrote: > I'm not targetting 2.4 -- my work is done on the current master. Adding > hundreds of lines to the current 2.4 for the purpose of supporting a library > which is not yet present on the user systems does not make much sense :) Currently, master and

Re: [Openvpn-devel] [PATCH applied] Re: Fix building with LibreSSL 2.5.1 by cleaning a hack. Similar to what is done in curl: https://github.com/curl/curl/blob/028391df5d84d9fae3433afdee9261d565900355

2017-02-17 Thread Olivier W
Hello Gert, 2017-02-16 8:47 GMT+01:00 Gert Doering : > Your patch has been applied to the master and release/2.4 branch. > > Not sure if it is something we want in release/2.3, but it wouldn't apply > with "git cherry-pick" - too much formatting changes, so one would need >

[Openvpn-devel] [PATCH] add --dev-pipe option, use stdio of forked process for network frames

2017-02-17 Thread Eric Wheeler
Hello all, I wrote this back in the openvpn-2.2-beta3 days and always wanted to submit the code but never got to it---so here it is! I used it with a userspace slirp-stdio implementation to get a tunnel without root priveleges. --dev-pipe /usr/local/bin/some_script arg1 arg2 ... arg15

[Openvpn-devel] [RFC PATCH v1 12/15] OpenSSL: don't use direct access to the internal of HMAC_CTX

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including HMAC_CTX. We have to use the defined functions to do so. Compatibility with OpenSSL 1.0 is kept by defining the corresponding functions when they are not found in the

[Openvpn-devel] [RFC PATCH v1 14/15] OpenSSL: check for the SSL reason, not the full error

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 changed the SSLv3 API and removed many SSL_L_SSL3_* constants. Moreover, new code might use different function code for the same error. Thus, we extract the error reason from the error code before we compare it instead of trying to rebuild an

[Openvpn-devel] [RFC PATCH v1 15/15] OpenSSL: constify getbio() parameters

2017-02-17 Thread logout
From: Emmanuel Deloget Although it is required by BIO_new() to have a non-const object, this is merely an OpenSSL interface accident. Newer versions of OpenSSL (i.e. OpenSSL 1.1) have are a bit better w.r.t. constification and changed this. As a result, we can safely constify

[Openvpn-devel] [RFC PATCH v1 10/15] OpenSSL: don't use direct access to the internal of EVP_MD_CTX

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including EVP_MD_CTX. We have to use the defined functions to do so. Compatibility with OpenSSL 1.0 is kept by defining the corresponding functions when they are not found in

[Openvpn-devel] [RFC PATCH v1 09/15] OpenSSL: don't use direct access to the internal of X509_STORE_CTX

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including X509_STORE_CTX. We have to use the defined functions to do so. Fortunately, these functions have existed since the dawn of time so we don't have any compatibility

[Openvpn-devel] [RFC PATCH v1 01/15] OpenSSL: don't use direct access to the internal of SSL_CTX

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including SSL_CTX. We have to use the defined functions to do so. Compatibility with OpenSSL 1.0 is kept by defining the corresponding functions when they are not found in the

[Openvpn-devel] [RFC PATCH v1 13/15] OpenSSL: SSLeay symbols are no longer available in OpenSSL 1.1

2017-02-17 Thread logout
From: Emmanuel Deloget The old symbols do not exist anymore but the library gained new equivalent symbols (OSSL). Use them instead of the old ones Signed-off-by: Emmanuel Deloget --- src/openvpn/openssl_compat.h | 5 + src/openvpn/ssl_openssl.c| 2 +- 2

[Openvpn-devel] [RFC PATCH v1 03/15] OpenSSL: don't use direct access to the internal of X509_OBJECT

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including X509_OBJECT. We have to use the defined functions to do so. Compatibility with OpenSSL 1.0 is kept by defining the corresponding functions when they are not found in

[Openvpn-devel] [RFC PATCH v1 11/15] OpenSSL: don't use direct access to the internal of EVP_CIPHER_CTX

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including EVP_CIPHER_CTX. We have to use the defined functions to do so. Compatibility with OpenSSL 1.0 is kept by defining the corresponding functions when they are not found

[Openvpn-devel] [RFC PATCH v1 05/15] OpenSSL: don't use direct access to the internal of X509

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including X509. We have to use the defined functions to do so. In x509_verify_ns_cert_type() in particular, this means that we cannot directly check for the extended flags to

[Openvpn-devel] [RFC PATCH v1 07/15] OpenSSL: don't use direct access to the internal of RSA

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including RSA. We have to use the defined functions to do so. Compatibility with OpenSSL 1.0 is kept by defining the corresponding functions when they are not found in the

[Openvpn-devel] [RFC PATCH v1 08/15] OpenSSL: don't use direct access to the internal of DSA

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including DSA. We have to use the defined functions to do so. Compatibility with OpenSSL 1.0 is kept by defining the corresponding functions when they are not found in the

[Openvpn-devel] [RFC PATCH v1 06/15] OpenSSL: don't use direct access to the internal of EVP_PKEY

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including EVP_PKEY. We have to use the defined functions to do so. Compatibility with OpenSSL 1.0 is kept by defining the corresponding functions when they are not found in the

[Openvpn-devel] [RFC PATCH v1 02/15] OpenSSL: don't use direct access to the internal of X509_STORE

2017-02-17 Thread logout
From: Emmanuel Deloget OpenSSL 1.1 does not allow us to directly access the internal of any data type, including X509_STORE. We have to use the defined functions to do so. Compatibility with OpenSSL 1.0 is kept by defining the corresponding functions when they are not found in

[Openvpn-devel] [RFC PATCH v1 00/15] Add support for OpenSSL 1.1.x

2017-02-17 Thread logout
From: Emmanuel Deloget The purpose of this RFC series is to make the latest master of OpenVPN (2.5-git) linkable with OpenSSL v1.1.x. It may not be complete (I may have missed something due to my work environment, but any missing pieces will be added next week) so be a bit

Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-17 Thread Emmanuel Deloget
Hello, On Fri, Feb 17, 2017 at 6:42 PM, Gert Doering wrote: > Hi, > > On Fri, Feb 17, 2017 at 06:37:04PM +0100, Emmanuel Deloget wrote: >> I guess the answer to the riddle is: "how long will the 2.4 branch >> live?". v2.3 shipped in May 2013. If we assume that v2.4 will be

Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-17 Thread Илья Шипицин
Пт, 17 февр. 2017 г. в 22:21, David Sommerseth < open...@sf.lists.topphemmelig.net>: > On 17/02/17 17:35, Emmanuel Deloget wrote: > > > > Now, I have a question which is related to this. The way I'm doing > > things, I will make sure that the new code is compatible with both > > OpenSSL 1.0.x and

Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-17 Thread Matthias Andree
Am 17.02.2017 um 17:35 schrieb Emmanuel Deloget: > I understand that I'm the new guy in town, but can you allow me to > make the formal request to ditch OpenSSL 0.9.8, 1.0.0 and 1.0.1 and > require at least version 1.0.2? 1.0.1 has also gone out of support, and I propose to let the distros sort

Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-17 Thread Gert Doering
Hi, On Fri, Feb 17, 2017 at 06:37:04PM +0100, Emmanuel Deloget wrote: > I guess the answer to the riddle is: "how long will the 2.4 branch > live?". v2.3 shipped in May 2013. If we assume that v2.4 will be the > stable branch for two more years (I cannot find any roadmap, so this > is pure

Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-17 Thread Emmanuel Deloget
Hello, On Fri, Feb 17, 2017 at 5:41 PM, Gert Doering wrote: > Hi, > > On Fri, Feb 17, 2017 at 05:35:04PM +0100, Emmanuel Deloget wrote: >> I understand that I'm the new guy in town, but can you allow me to >> make the formal request to ditch OpenSSL 0.9.8, 1.0.0 and 1.0.1

Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-17 Thread David Sommerseth
On 17/02/17 17:35, Emmanuel Deloget wrote: > > Now, I have a question which is related to this. The way I'm doing > things, I will make sure that the new code is compatible with both > OpenSSL 1.0.x and OpenSSL 1.1. There is a good chance that it will be > compatible with version 0.9.8 as well,

Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-17 Thread Gert Doering
Hi, On Fri, Feb 17, 2017 at 05:35:04PM +0100, Emmanuel Deloget wrote: > I understand that I'm the new guy in town, but can you allow me to > make the formal request to ditch OpenSSL 0.9.8, 1.0.0 and 1.0.1 and > require at least version 1.0.2? I'm not going to make a call on any of these

Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-17 Thread Emmanuel Deloget
Hello, First, sorry for the inconvenience: this message is not attached to the remaining of the discussion (I just joined the ML so I cannot answer to a one week old message). That being said: On Mon, Feb 13, 2017 at 08:17:58PM +0100, Christian Hesse wrote: > Arch Linux is about to upgrade

[Openvpn-devel] [PATCH v2] Allow changing cipher from a ccd file

2017-02-17 Thread Steffan Karger
As described in msg <374a7eb7-f539-5231-623b-41f208ed8...@belkam.com> on openvpn-devel@lists.sourceforge.net, clients that are compiled with --disable-occ (included in --enable-small) won't send an options string. Without the options string, the 2.4 server doesn't know which cipher to use for

Re: [Openvpn-devel] [PATCH] Feedback wanted: proof-of-concept recvmmsg() support

2017-02-17 Thread Steffan Karger
Hi David, Thanks for the comments. On 25-01-17 18:25, David Sommerseth wrote: > First of all, not all kernels carry these system calls, I believe they > were added in some of the 3.x kernels - but, IIRC, it has been > backported to at least the RHEL6 2.6.32 kernels. My memory is scarce > about