Just basic compile + t_client tested (which will excercise --ncp-ciphers
a bit, but not add any "unsupported optionals" today).
Your patch has been applied to the master branch.
commit 6bbd89c5c82e7a2366ecac969b35f88797a73763
Author: Arne Schwabe
Date: Mon Oct 10 17:55:15 2022 +0200
Ensur
On Mon, Oct 10, 2022 at 05:55:15PM +0200, Arne Schwabe wrote:
> Make sure cipher_valid only considered these four operations as valid.
"considers"
> This fixes that somjething like --data-ciphers AES-256-GCM:AES-128-CCM
"something"
> will start but later fail when trying to use the CCM cipher.
Make sure cipher_valid only considered these four operations as valid.
This fixes that somjething like --data-ciphers AES-256-GCM:AES-128-CCM
will start but later fail when trying to use the CCM cipher.
We say "a supported AEAD" mode in our error since CCM is also an AEAD mode
but one we support
Make sure cipher_valid only considered these four operations as valid.
This fixes that somjething like --data-ciphers AES-256-GCM:AES-128-CCM
will start but later fail when trying to use the CCM cipher.
We say "a supported AEAD" mode in our error since CCM is also an AEAD mode
but one we support
Acked-by: Gert Doering
Thanks for providing a v3, and following our sometimes difficult rules
for patch submission.
I have tested this with v4 and v6 connections, and it looks good:
PLUGIN AUTH-PAM: BACKGROUND: REMOTE: 2001:608:0:814::f000:21
PLUGIN AUTH-PAM: BACKGROUND: REMOTE: 194.97.14
On Sonntag, 26. Juni 2022 01:41:48 CEST Arne Schwabe wrote:
> To maximise compatibility allow to lie our MTU in the default OCC
> message.
>
> Patch v2: improve documentation
> Patch v3: split changing default MTU into its own patch
Doesn't apply to master anymore. From what I have seen, besides
From: paolo
- styled code as openvpn
- added check for remote, if NULL after all get_env, put to point to empy string
Signed-off-by: Paolo Cerrito
---
src/plugins/auth-pam/auth-pam.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/src/plugins/
Hi,
On Mon, Oct 10, 2022 at 10:00:37AM +0200, Antonio Quartulli wrote:
> > -if (username)
> > +if (username && *username)
>
> super uber nitpick (bike shadding level):
>
> I think in other places we perform the very same check using the format:
> username[0] instead of *username
Hi,
On 10/10/2022 09:12, Gert Doering wrote:
We do not permit username changes on renegotiation (= username is
"locked" after successful initial authentication).
Unfortunately the way this is written this gets in the way of using
auth-user-pass-optional + pushing "auth-token-user" from client-c
Hi,
On Sun, Oct 09, 2022 at 03:51:36PM +0200, Gert Doering wrote:
> Recording David's and Heiko's ACK, they have done the stare-at-code
> and actual testing (I have run t_client tests, but they do not excercise
> this problem with my current test servers - need to add more variants).
Just for the
We do not permit username changes on renegotiation (= username is
"locked" after successful initial authentication).
Unfortunately the way this is written this gets in the way of using
auth-user-pass-optional + pushing "auth-token-user" from client-connect
(and most likely also "from management")
11 matches
Mail list logo
