Commit ("openssl: Fix compilation without deprecated OpenSSL 1.1 APIs")
has removed the cipher_ctx_cleanup() API, as it is not anymore required
to be a distinct call. However, while doing so it also touched the
mbedtls backend in a wrong way causing a systematic segfault upon connection.
Hi,
On Fri, Aug 16, 2019 at 09:31:52PM +0200, Gert Doering wrote:
> Your patch has been applied to the master branch.
>
> Is this also suitable for release/2.4? "You folks tell me, I do the
> cherry-picking" (if it applies) :-)
>
> I have removed the extra spaces in "# if" constructs, as this
From: Antonio Quartulli
Networking backend implementations may need to allocate dynamic
resources that require an explicit free/release.
Since these cleanup are perfomed not very often, and only at specific
times, it makes sense to have the upper layer signal when it's the right
time to do so,
On Fri, Aug 16, 2019 at 12:31 PM Gert Doering wrote:
>
> Your patch has been applied to the master branch.
>
> Is this also suitable for release/2.4? "You folks tell me, I do the
> cherry-picking" (if it applies) :-)
2.4 is what I did my testing on, so yes.
>
> I have removed the extra spaces in
Your patch has been applied to the master branch.
Is this also suitable for release/2.4? "You folks tell me, I do the
cherry-picking" (if it applies) :-)
I have removed the extra spaces in "# if" constructs, as this is not
something we use elsewhere on nested CPP expressions (it came up in the
Hi,
On Fri, Aug 16, 2019 at 07:13:14PM +0200, David Sommerseth wrote:
> On 08/08/2019 16:51, Arne Schwabe wrote:
> > The previous auth-token implementation had a serious problem, especially
> > when
> > paired with an unpatched OpenVPN client that keeps trying the auth-token
> > (commit
On 08/08/2019 16:52, Arne Schwabe wrote:
> From: Arne Schwabe
>
> This allows an external authentication method
> (e.g. management interface) to track the connection and distinguish a
> reconnection from multiple connections.
>
> Addtionally this now also checks to workaround a problem with
>
Wow, more ACKs than actual lines of codes affected .-) - I hear you
wrt "have a #define somewhere" (and yes, we could do that) or "make it
easier to configure for users" (nah... for the reasons Antonio gave) :-)
Patch has been applied to the master and release/2.4 branch.
2.4, because (see the
Hi,
On Fri, Aug 16, 2019 at 05:22:27PM +0200, Antonio Quartulli wrote:
> The reason why I ask is that adding a new crypto backend drastically
> increases the maintenance cost for us.
... and since we're already struggling with providing proper maintenance
and getting new stuff integrated in a
On 08/08/2019 16:51, Arne Schwabe wrote:
> The previous auth-token implementation had a serious problem, especially when
> paired with an unpatched OpenVPN client that keeps trying the auth-token
> (commit e61b401a).
>
> The auth-token-gen implementation forgot the auth-token on reconnect, this
>
Hi Juliusz,
On 16/08/2019 16:14, Juliusz Sosinowicz wrote:
> This patch adds the option to use wolfSSL as the ssl backend. To build
> this patch:
>
> 1. wolfSSL needs to be built with the `--enable-all` configure option.
> 2. OpenVPN must be built with the `--with-crypto-library=wolfssl`
>
Am 16.08.19 um 16:14 schrieb Juliusz Sosinowicz:
> This patch adds the option to use wolfSSL as the ssl backend. To build
> this patch:
>
That is great and it is also a very big patch. I skimmed only through
the patch.
+#ifdef ENABLE_CRYPTO_WOLFSSL
+o->ciphername = "AES-256-CBC";
+#else
Hi,
On 16/08/2019 13:49, David Sommerseth wrote:
> On 15/08/2019 17:53, Gert Doering wrote:
>> For reasons historically unknown, OpenVPN sets the listen() backlog
>> queue to "1", which signals the kernel "while there is one TCP connect
>> waiting for OpenVPN to handle it, refuse all others" -
This patch adds the option to use wolfSSL as the ssl backend. To build
this patch:
1. wolfSSL needs to be built with the `--enable-all` configure option.
2. OpenVPN must be built with the `--with-crypto-library=wolfssl`
configure option.
Documentation regarding the wolfSSL SSL library may
On 15/08/2019 17:53, Gert Doering wrote:
> For reasons historically unknown, OpenVPN sets the listen() backlog
> queue to "1", which signals the kernel "while there is one TCP connect
> waiting for OpenVPN to handle it, refuse all others" - which, on
> restarting a busy TCP server, will create
On 16/08/2019 10:27, Rolf Fokkens via Openvpn-devel wrote:
> We're considering to use shorter-lived client certificates for our VPN
> users. In an effort to prevent negative impact for our staff due to
> expired certificates, we 'd like to keep track of imminent expiration
> of certificates in the
We're considering to use shorter-lived client certificates for our VPN
users. In an effort to prevent negative impact for our staff due to
expired certificates, we 'd like to keep track of imminent expiration
of certificates in the client-connect script (which we're using anyway
to check is the
17 matches
Mail list logo