[Openvpn-devel] [PATCH applied] Re: build: Remove --disable-server from ./configure

2020-05-07 Thread Gert Doering
Your patch has been applied to the master branch. Due to the recent uncrustify changes, mbedTLS bugfixes and lev's key state / NCP changes, this needed a bit more force to go in - but in the end, the changes are totally straightforward, and I've verified that the code changes "after the fact" are

[Openvpn-devel] Summary of the community meeting (7th May 2020)

2020-05-07 Thread Samuli Seppänen
Hi, Here's the summary of the IRC meeting. --- COMMUNITY MEETING Place: #openvpn-meeting on irc.freenode.net Date: Thu 7th May 2020 Time: 20:00 CEST (18:00 UTC) Planned meeting topics for this meeting were here: Your local

[Openvpn-devel] [PATCH applied] Re: convert *_inline attributes to bool

2020-05-07 Thread Gert Doering
I have diffed v9 and v11, and the only change is the unit test related stuff. Unit tests pass with this version, so I assume it's good :-) I take the ACK from Arne for v9 (because the main code change is the same). Client-tested on Linux and FreeBSD, though only with a very simple inline config

[Openvpn-devel] [PATCH v11] convert *_inline attributes to bool

2020-05-07 Thread Antonio Quartulli
Carrying around the INLINE_TAG is not really efficient, because it requires a strcmp() to be performed every time we want to understand if the data is stored inline or not. Convert all the *_inline attributes to bool to make the logic easier and checks more efficient. Signed-off-by: Antonio

[Openvpn-devel] [PATCH v10] convert *_inline attributes to bool

2020-05-07 Thread Antonio Quartulli
Carrying around the INLINE_TAG is not really efficient, because it requires a strcmp() to be performed every time we want to understand if the data is stored inline or not. Convert all the *_inline attributes to bool to make the logic easier and checks more efficient. Signed-off-by: Antonio

[Openvpn-devel] [PATCH v4] Do not write extra 0 byte for --gen-key with auth-token/tls-crypt-v2

2020-05-07 Thread Arne Schwabe
Change crypto_pem_encode to not put a nul-terminated terminated string into the buffer. This was useful for printf but should not be written into the file. Instead do not assume that the buffer is null terminated and print only the number of bytes in the buffer. Also fix a similar case in

[Openvpn-devel] [PATCH applied] Re: Use crypto library functions for const time memcmp when possible

2020-05-07 Thread Gert Doering
Acked-by: Gert Doering I still feel it hurts my eyes, and is way overcomplicating things, but if this is what mbedtls is using internally (why are they not exporting it??!), it should be good enough for us. Further, as it's not being used for AEAD anyway, I withdraw my "performance" argument

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

2020-05-07 Thread Juliusz Sosinowicz
Hi Antonio, thank you for reviewing and testing OpenVPN with wolfSSL. Let me explain the warnings: On 07/05/2020 12:28, Antonio Quartulli wrote: Hi Juliusz, There are some warnings when compiling with wolfssl v4.0.0-stable: In file included from crypto_openssl.c:44: openssl_compat.h:93:

Re: [Openvpn-devel] [PATCH applied] Re: Parse static challenge response in auth-pam plugin

2020-05-07 Thread Gert Doering
Hi, On Thu, Apr 23, 2020 at 10:02:10AM -0400, Selva Nair wrote: > On Tue, Aug 7, 2018 at 3:01 PM Gert Doering wrote: > > Your patch has been applied to the master branch. > > > > (I'm a bit undecided about release/2.4 - this is in "new feature!" land, > > and all the challenge stuff is "master"

[Openvpn-devel] [PATCH applied] Re: t_net.sh: assign MAC address directly during interface creation

2020-05-07 Thread Gert Doering
Acked-by: Gert Doering "If you say this helps" :-) (it's test code, and it seems to stop the spurious t_net failure triggers on some linux variants) Your patch has been applied to the master branch. commit 3cb9b156c8094ab333fc4f3da57818471135ac5e Author: Antonio Quartulli Date: Tue Apr 28

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

2020-05-07 Thread Juliusz Sosinowicz
Hi Arne, currently it is macro'ed to wolfSSL_lib_version which only returns the version string. I will add our library name to the front of the OpenSSL_version return string. Thanks, Juliusz On 07/05/2020 12:35, Arne Schwabe wrote: Am 07.05.20 um 12:28 schrieb Antonio Quartulli: Thu May

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

2020-05-07 Thread Arne Schwabe
Am 07.05.20 um 12:28 schrieb Antonio Quartulli: > Thu May 7 12:16:12 2020 library versions: 4.4.0, LZO 2.10 Additionally it seems the OpenSSL_version(OPENSSL_VERSION) function does not include the library name. OpenSSL reports itself here: library versions: OpenSSL 1.1.1g 21 Apr 2020 also

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

2020-05-07 Thread Antonio Quartulli
Hi Juliusz, There are some warnings when compiling with wolfssl v4.0.0-stable: In file included from crypto_openssl.c:44: openssl_compat.h:93: warning: "EVP_CIPHER_CTX_reset" redefined 93 | #define EVP_CIPHER_CTX_reset EVP_CIPHER_CTX_init | In file included from crypto_openssl.h:32,

Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

2020-05-07 Thread Arne Schwabe
Am 29.04.20 um 16:51 schrieb Juliusz Sosinowicz: > This patch adds support for wolfSSL in OpenVPN. Support is added by using > wolfSSL's OpenSSL compatibility layer. Function calls are left unchanged and > instead the OpenSSL includes point to wolfSSL headers and OpenVPN is linked > against the