On 05/08/2020 21:25, Steffan Karger wrote:
Hi,
No full review yet, but this version does seem to address my previous
comments. Some minor nits I noticed on my first run through v2:
On 29-07-2020 13:38, Arne Schwabe wrote:
This reworks the NCP logic to be more strict about what is
Hi,
No full review yet, but this version does seem to address my previous
comments. Some minor nits I noticed on my first run through v2:
On 29-07-2020 13:38, Arne Schwabe wrote:
> This reworks the NCP logic to be more strict about what is
> considered an acceptable result of an NCP negotiation.
Acked-by: Gert Doering
Thanks. Tested that it indeed fixes things, and that it is
not necessary for 2.4 (compile-tested only).
Added "trac #1308" to the commit message.
Your patch has been applied to the master branch.
commit dab34fdd0639c6de8c5ca759cca00b7e60da32f1
Author: Lev Stipakov
Hi,
On Wed, Aug 05, 2020 at 05:27:45PM +0500, Vladislav Grishenko wrote:
> Thank you.
> I'd appreciate if patch could be applied to release/2.4 too, no changes are
> required - related code is the same, just hunks offset in ssl_verify.c and
> ssl_verify_openssl.c
> I've tested 2.4.9
Hi, Gert
Thank you.
I'd appreciate if patch could be applied to release/2.4 too, no changes are
required - related code is the same, just hunks offset in ssl_verify.c and
ssl_verify_openssl.c
I've tested 2.4.9 [git:release/2.4/7c428ca19a8df6b9+] with patch on sample
certificates, please refer log
Your patch has been applied to the master branch.
I have not done much testing, just a test run "make check" on an
OpenSSL and mbedTLS build.
I have not looked into applying it to "release/2.4" - if you think
it's needed, let me know (or if it needs more work because the code
has diverged too
Hi,
On Wed, Aug 05, 2020 at 08:43:18AM +0200, Gert Doering wrote:
> Test run with "cipher bf-cbc" in all server configs next...
For completeness, this works nicely:
start client jobs...
22...
Test sets succeeded: 1 2 3 4 6 8.
Test sets failed: none.
23.small...
Test sets succeeded: 1 2 3 4.
Code looks good. Compiled and tested (openssl and revoked cert) on Ubuntu 20.04.
Acked-by: Lev Stipakov
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
As it appears commit 767e4c56becbfeea525e4695a810593f373883cd "Log
serial number of revoked certificate" hasn't survive refactoring
of CRL handling.
In most of situations admin of OpenVPN server needs to know which
particular certificate is used by client.
In the case when certificate is valid,
Hi,
+ASSERT(snprintf(ifname, sizeof(ifname), "utun%d", utunnum));
Not sure about ASSERT here, because according to
https://linux.die.net/man/3/snprintf
> If an output error is encountered, a negative value is returned.
which won't trigger assert.
Otherwise looks good.
Compiled
Hi, Lev
Thanks for review, I'll make improvements in V2.
--
Best Regards, Vladislav Grishenko
-Original Message-
From: Lev Stipakov
Sent: Wednesday, August 5, 2020 1:29 PM
To: Vladislav Grishenko
Cc: openvpn-devel
Subject: Re: [Openvpn-devel] [PATCH] Log serial number of revoked
Hi,
Compiled and tested on Ubuntu 20.04, looks good.
A few nit-picks:
> +verify_check_crl_dir(const char *crl_dir, int cert_depth,
> openvpn_x509_cert_t *cert, char *subject)
The last parameter could benefit from const to indicate that function
is not going to modify it.
> -
HI,
On Wed, Aug 05, 2020 at 12:20:54AM +0200, Arne Schwabe wrote:
> > Is that intentional?
>
> Yes. That is intentional. If you do not have any cipher option in the
> config, there is nowadays a very high change that you allow BF-CBC by
> "accident". I encountered this first-hand ("I do want to
struct compress_options is defined under USE_COMP, therefore
compilation fails when it is referenced without that define.
Since function show_compression_warning, which uses aforementioned
struct, is only called under USE_COMP, it is safe to wrap its definition
under USE_COMP, which fixes
14 matches
Mail list logo
