Hi,
On Sun, Nov 10, 2019 at 05:03:26PM -0500, Selva Nair wrote:
> > the
> > > temptation to add -Werror in general and to Windows cross-build in
> > > particular.
> >
> > Yeah, we're not intending to.
>
> But the patch does affect cross-compilation for Windows on linux.
That seems to have been a
Samuli Seppänen ：
> The error is pretty clear:
>
> Error 0x800b0109: A certificate chain processed, but terminated in a
> root certificate which is not trusted by the trust provider.
>
> Is your computer perhaps behind in Windows updates? My hunch is that
> Digicert's latest root certificate is not
Since mbed TLS 2.18, mbed TLS can also implement RFC 5705. As a first
step towards using the keying material exporter as a method to generate
key material for the data channel, implement the
--keying-material-exporter function we already have for OpenSSL also for
mbed TLS builds.
Implementing RFC
Forgot to hit send on this, and probably this is only partially relevant
now, but here goes.
Hi
On Sun, Nov 10, 2019 at 12:03 PM Gert Doering wrote:
> Hi,
>
> On Sun, Nov 10, 2019 at 11:48:16AM -0500, Selva Nair wrote:
> > But it seems it may also affect mingw builds on travis. I would resist
>
CFLAGS may not resolve to anything and the build-check.sh script would
just fail.
Switch to EXTRA_FLAGS and use proper substitution so that the script won't
error out when EXTRA_FLAGS is uninitialized.
At the same time ensure that such flag is set only when compiling *for*
linux (we use linux to
NAK to myself!
Even though travis was green, this patch does not properly activate
-Werror..
v2 incoming..
Cheers,
--
Antonio Quartulli
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listi
CFLAGS may not resolve to anything and the build-check.sh script would
just fail.
Use proper substitution so that the script won't error out when CFLAGS
is uninitialized.
At the same time ensure that such flag is set only when compiling *for*
linux (we use linux to also compile *for* windows)
Si
Hi,
On Mon, Nov 04, 2019 at 05:10:12AM +0800, Tom Yan wrote:
> So in master, when net_addr_v4_add is called in tun.c, which
> net_addr_v4_add (networking_iproute2.c or networking_sitnl.c) is
> actually used depends on how openvpn is built, right?
Can you have a look at the current "master" branch
Your patch has been applied to the master branch.
commit 1513489be632f6577021e3a0f51799b59c4ace6a
Author: Antonio Quartulli
Date: Sun Nov 10 14:35:25 2019 +0100
travis: compile with -Werror on Linux
Signed-off-by: Antonio Quartulli
Acked-by: Arne Schwabe
Message-Id: <2019
Hi,
On Sun, Nov 10, 2019 at 11:48:16AM -0500, Selva Nair wrote:
> But it seems it may also affect mingw builds on travis. I would resist the
> temptation to add -Werror in general and to Windows cross-build in
> particular.
Yeah, we're not intending to.
The plan is to have "default builds (no co
Your patch has been applied to the master branch.
(Resending with correct "Acked-by" line - I noticed after I sent the mail
but before pushing, so I amended the commit and here's the right ID)
commit 6c7b41c6536b221b1e2bc26a26ae6814a71d69e8
Author: Antonio Quartulli
Date: Sun Nov 10 14:35:24 20
Your patch has been applied to the master branch.
(Resent with correct Acked-By:)
commit 9d0b95c45130af2f91fa2195c483e2c7461c0f40
Author: Antonio Quartulli
Date: Sun Nov 10 14:35:23 2019 +0100
auth_token_kt: ensure key_type object is initialized
Signed-off-by: Arne Schwabe
Sig
Your patch has been applied to the master branch.
(Resending with correct "Acked-by" line - I noticed after I sent the mail
but before pushing, so I amended the commit and here's the right ID)
commit 6c7b41c6536b221b1e2bc26a26ae6814a71d69e8
Author: Antonio Quartulli
Date: Sun Nov 10 14:35:24 20
Your patch has been applied to the master branch.
commit 7122af670d58586d9806214c81d27c424b226730
Author: Antonio Quartulli
Date: Sun Nov 10 14:35:24 2019 +0100
auth.c: make cast explicit in the crypto API
Signed-off-by: Antonio Quartulli
Acked-by: Gert Doering
Message-Id
Your patch has been applied to the master branch.
commit 9c380048a36cd1d1565607b5a0bee0ebbb8b1465
Author: Antonio Quartulli
Date: Sun Nov 10 14:35:23 2019 +0100
auth_token_kt: ensure key_type object is initialized
Signed-off-by: Arne Schwabe
Signed-off-by: Antonio Quartulli
Hi,
On Sun, Nov 10, 2019 at 8:36 AM Antonio Quartulli wrote:
> Signed-off-by: Antonio Quartulli
> ---
> .travis/build-check.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.travis/build-check.sh b/.travis/build-check.sh
> index 039a7dcf..250bb454 100755
> --- a/.travis/build-check.
Am 10.11.19 um 14:35 schrieb Antonio Quartulli:
> Signed-off-by: Antonio Quartulli
> ---
> .travis/build-check.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.travis/build-check.sh b/.travis/build-check.sh
> index 039a7dcf..250bb454 100755
> --- a/.travis/build-check.sh
> +++ b/.tra
Am 10.11.19 um 14:35 schrieb Antonio Quartulli:
> mbedtls_md_get_size() returns unsigned char, while EVP_MD_size() returns
> int. Results coming from both functions are normally in a uint8_t member
> of the key_type struct, because it is known that 8bits are enough (also
> for EVP_MD_size()).
>
>
Am 10.11.19 um 14:35 schrieb Antonio Quartulli:
> Fixes the following warning:
>
> auth_token.c: In function 'auth_token_init_secret':
> auth_token.c:47: warning: 'kt.cipher_length' is used uninitialized in this
> function
> auth_token.c:34: note: 'kt.cipher_length' was declared here
>
> Signed-
mbedtls_md_get_size() returns unsigned char, while EVP_MD_size() returns
int. Results coming from both functions are normally in a uint8_t member
of the key_type struct, because it is known that 8bits are enough (also
for EVP_MD_size()).
This unexpected cast can, however, trigger unsolicited warni
Signed-off-by: Antonio Quartulli
---
.travis/build-check.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/.travis/build-check.sh b/.travis/build-check.sh
index 039a7dcf..250bb454 100755
--- a/.travis/build-check.sh
+++ b/.travis/build-check.sh
@@ -8,6 +8,7 @@ fi
if [ "${TRAVIS_OS_NAME}"
Fixes the following warning:
auth_token.c: In function 'auth_token_init_secret':
auth_token.c:47: warning: 'kt.cipher_length' is used uninitialized in this
function
auth_token.c:34: note: 'kt.cipher_length' was declared here
Signed-off-by: Arne Schwabe
Signed-off-by: Antonio Quartulli
---
src
Acked-by: Gert Doering
Thanks. Patch looks good ("stared-at-code") and since the buildbot army
is running sufficient t_client tests nowadays to actually catch runtime
brokenness for "standard cases", this looks good.
I'll amuse myself testing /31 across the platforms in the next days, just
bec
From: Lev Stipakov
Implemented according to Wintun documentation
and reference client code.
Wintun uses ring buffers to communicate between
kernel driver and user process. Client allocates
send and receive ring buffers, creates events
and passes it to kernel driver under LocalSystem
privileges.
Hi,
As a general remark: could you try to stick to the 80 char line length
> limit?
>
Ok.
> > +#ifdef _WIN32
> > +}
> > #endif
>
> As Simon mentioned too, this code is getting more and more hard to read.
> Can we maybe do this in some cleaner way? Maybe add some helper
> function(s)?
>
Al
The broadcast argument is actually useless as every platform will figure
it out and configure it on its own. We even realized that on linux, if
you configure it wrong, nothing wrong will happen.
At this point, let's make the code cleaner and let's get rid of this
useless argument at all.
This pat
Acked-by: Gert Doering
After a quick discussion in the group, we're all OK with kicking out
static-key samples (only the samples, not the functionality yet) BUT
we can't do the AES-256-GCM thing in 2.4 due to "RHEL6 and Debian 8"
support (no AES-GCM there). So, master.
Your patch has been appl
Acked-by: Gert Doering
While I'm not exactly happy suppressing warnings, this particular one
is somewhat of an annoyance - the two cases where we cause warnings
today are perfectly fine, and working around spurious compiler warnings
is not what I want to spend our time on. We can revisit this l
GCC>=8 supports truncation checking, however the logic is somewhat
fragile when it comes to evaluating strncpy().
In buffer.h we have implemented a wrapper called strncpynt() which
ensures we always do the right hting in the code and reduce the chance
of having bugs.
This said, it seems that the
On 09/11/2019 16:46, Steffan Karger wrote:
>> static void
>> add_option(struct options *options,
>> @@ -7322,29 +7339,78 @@ add_option(struct options *options,
>> }
>> #endif
>> #if defined(USE_COMP)
>> +else if (streq(p[0], "allow-compression") && p[1] && !p[2])
>> +{
>> +
30 matches
Mail list logo
