date:20170221

Re: [Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

2017-02-21 Thread Gert Doering

Hi,

On Wed, Feb 22, 2017 at 02:21:35AM +0100, David Sommerseth wrote:
> >> >From d97f526a2ddbf2abe60a64260601ebd742fc00cc Mon Sep 17 00:00:00 2001
> >> From: "Simon (simix)" 
> > 
> > Do we have a policy how to handle patches with missing author info?
> 
> I see no reason at all why we should not give proper credit with full
> name.  

That was only half the question - of course I *want* to give full credits,
but is "not having this information available & no SoB line" a reason
for rejecting a patch?

The patch in question is quite obvious, so this is not something to bring
in the lawyers - more a matter of general policy.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] build against openssl 1.1.0

2017-02-21 Thread David Sommerseth

On 13/02/17 21:16, David Sommerseth wrote:
> On 13/02/17 20:50, Christian Hesse wrote:
>> And a lot more has to be done... There's a long list of packages to be
>> fixed. Sadly openssl developers do not care about ABI and API stability
>> or compatibility. :(
> 
> I do understand the frustration ... but lets be fair too.  OpenSSL v1.1
> is considered a major upgrade from v1.0 and they don't guarantee API/ABI
> stability across major upgrades.
> 
> And the v1.1 API does indeed try to clean up a lot of the API mess and
> confusions.  So it is a move in the right direction.  I attended an
> OpenSSL v1.1 talk at devconf.cz in the end of January this year, I'll
> try to dig up the slides from Tomas Mraz who had the talk.  It was quite
> informative why it was needed to break several APIs in v1.1.

Finally!

Here's a video of the presentation:



-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

2017-02-21 Thread David Sommerseth

On 21/02/17 22:12, Gert Doering wrote:
> Hi,
> 
> On Tue, Feb 21, 2017 at 08:42:57PM +0100, Steffan Karger wrote:
>> ACK to the attached patch.
> 
>> >From d97f526a2ddbf2abe60a64260601ebd742fc00cc Mon Sep 17 00:00:00 2001
>> From: "Simon (simix)" 
> 
> All previous commits (I'm aware of) carry a valid e-mail address, and
> most of them have a full name for the author.
> 
> Do we have a policy how to handle patches with missing author info?

I see no reason at all why we should not give proper credit with full
name.  And we want to be able to reach out to people if there are issues
we can't figure out.  And since I'm one who likes consistency, I think
the policy should be the same for both large as well as small patches.

If someone have issues with that they can get in touch with Samuli or me
directly, as we are employed by OpenVPN Technologies.  Then we will sort
out the details and figure out who will get the credit in the end.

And we should see the Signed-off-by (SoB) line as well.  This carries
more importance if there are legal issues later on (intellectual
property issues, copyright infringements, etc).  The SoB line basically
indicates that "Yes, I am allowed to share this contribution for
inclusion".  The OpenVPN project is far to big to be ignorant to these
possible challenges.  And we never knows whom will be a victim for the
next patent troll.

With that said, I am far more relaxed to the SoB when it comes to
documentation and text snippets (unless it is a massive contribution).

-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc

signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

2017-02-21 Thread Steffan Karger

Hi,

On 21-02-17 22:12, Gert Doering wrote:
> On Tue, Feb 21, 2017 at 08:42:57PM +0100, Steffan Karger wrote:
>> ACK to the attached patch.
> 
>> >From d97f526a2ddbf2abe60a64260601ebd742fc00cc Mon Sep 17 00:00:00 2001
>> From: "Simon (simix)" 
> 
> All previous commits (I'm aware of) carry a valid e-mail address, and
> most of them have a full name for the author.
> 
> Do we have a policy how to handle patches with missing author info?

I don't know, but thought this was more reasonable than claiming
authorship.  We could try to reach out on trac first, and see if Simon
is willing to provide a full name and email address.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 09/15] OpenSSL: don't use direct access to the internal of X509_STORE_CTX

2017-02-21 Thread Steffan Karger

Hi,

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> OpenSSL 1.1 does not allow us to directly access the internal of
> any data type, including X509_STORE_CTX. We have to use the defined
> functions to do so.
> 
> Fortunately, these functions have existed since the dawn of time so
> we don't have any compatibility issue here.
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  src/openvpn/ssl_verify_openssl.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/src/openvpn/ssl_verify_openssl.c 
> b/src/openvpn/ssl_verify_openssl.c
> index 
> edc709b89eb05bca895639dde606b29f8e1f7024..5bdd1e3609c4a2693e16c0835a9e5c39babd5ff8
>  100644
> --- a/src/openvpn/ssl_verify_openssl.c
> +++ b/src/openvpn/ssl_verify_openssl.c
> @@ -62,14 +62,15 @@ verify_callback(int preverify_ok, X509_STORE_CTX *ctx)
>  session = (struct tls_session *) SSL_get_ex_data(ssl, mydata_index);
>  ASSERT(session);
>  
> -struct buffer cert_hash = x509_get_sha256_fingerprint(ctx->current_cert, 
> &gc);
> -cert_hash_remember(session, ctx->error_depth, &cert_hash);
> +X509 *current_cert = X509_STORE_CTX_get_current_cert(ctx);
> +struct buffer cert_hash = x509_get_sha256_fingerprint(current_cert, &gc);
> +cert_hash_remember(session, X509_STORE_CTX_get_error_depth(ctx), 
> &cert_hash);
>  
>  /* did peer present cert which was signed by our root cert? */
>  if (!preverify_ok)
>  {
>  /* get the X509 name */
> -char *subject = x509_get_subject(ctx->current_cert, &gc);
> +char *subject = x509_get_subject(current_cert, &gc);
>  
>  if (!subject)
>  {
> @@ -77,11 +78,11 @@ verify_callback(int preverify_ok, X509_STORE_CTX *ctx)
>  }
>  
>  /* Log and ignore missing CRL errors */
> -if (ctx->error == X509_V_ERR_UNABLE_TO_GET_CRL)
> +if (X509_STORE_CTX_get_error(ctx) == X509_V_ERR_UNABLE_TO_GET_CRL)
>  {
>  msg(D_TLS_DEBUG_LOW, "VERIFY WARNING: depth=%d, %s: %s",
> -ctx->error_depth,
> -X509_verify_cert_error_string(ctx->error),
> +X509_STORE_CTX_get_error_depth(ctx),
> +X509_verify_cert_error_string(X509_STORE_CTX_get_error(ctx)),
>  subject);
>  ret = 1;
>  goto cleanup;
> @@ -89,8 +90,8 @@ verify_callback(int preverify_ok, X509_STORE_CTX *ctx)
>  
>  /* Remote site specified a certificate, but it's not correct */
>  msg(D_TLS_ERRORS, "VERIFY ERROR: depth=%d, error=%s: %s",
> -ctx->error_depth,
> -X509_verify_cert_error_string(ctx->error),
> +X509_STORE_CTX_get_error_depth(ctx),
> +X509_verify_cert_error_string(X509_STORE_CTX_get_error(ctx)),
>  subject);
>  
>  ERR_clear_error();
> @@ -99,7 +100,7 @@ verify_callback(int preverify_ok, X509_STORE_CTX *ctx)
>  goto cleanup;
>  }
>  
> -if (SUCCESS != verify_cert(session, ctx->current_cert, ctx->error_depth))
> +if (SUCCESS != verify_cert(session, current_cert, 
> X509_STORE_CTX_get_error_depth(ctx)))
>  {
>  goto cleanup;
>  }
> 

ACK.  Changes look good and tested against OpenSSL 0.9.8, 1.0.0, 1.0.1
and 1.0.2.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: dev-tools: lz4-rebaser tool carried a typo

2017-02-21 Thread Gert Doering

ACK.  

Oh the annoyance :-(  - I *did* test-runs, but "it looked reasonable",
and I did not verify that the result *compiled*.  I should have...

Your patch has been applied to the master branch.

commit 40d6d471ff72e6a5e46911a3205f8e4401f506a3
Author: David Sommerseth
Date:   Tue Feb 21 20:27:35 2017 +0100

 dev-tools: lz4-rebaser tool carried a typo

 Signed-off-by: David Sommerseth 
 Acked-by: Gert Doering 
 Message-Id: <20170221192737.24166-2-dav...@openvpn.net>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14136.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

2017-02-21 Thread Gert Doering

Hi,

On Tue, Feb 21, 2017 at 08:42:57PM +0100, Steffan Karger wrote:
> ACK to the attached patch.

> >From d97f526a2ddbf2abe60a64260601ebd742fc00cc Mon Sep 17 00:00:00 2001
> From: "Simon (simix)" 

All previous commits (I'm aware of) carry a valid e-mail address, and
most of them have a full name for the author.

Do we have a policy how to handle patches with missing author info?

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

2017-02-21 Thread Steffan Karger

Hi,

The attached patch from trac #825 fixes a silly bug in my --tls-crypt
code.  I already confirmed this in trac, but now also on the list:

ACK to the attached patch.

-Steffan
>From d97f526a2ddbf2abe60a64260601ebd742fc00cc Mon Sep 17 00:00:00 2001
From: "Simon (simix)" 
Date: Tue, 21 Feb 2017 20:34:15 +0100
Subject: [PATCH] Fix segfault when using crypto lib without AES-256-CTR or
 SHA256

Openvpn segfaults on RHEL5/CentOS5 when using --tls-crypt, because it
doesn't have AES-256-CTR support:

openvpn[15330]: OpenVPN 2.4.0 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] built on Jan 17 2017
openvpn[15330]: library versions: OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008, LZO 2.09, LZ4 1.7.5
openvpn[15331]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
kernel: openvpn[15331]: segfault at 0008 rip 0040ebe0 rsp 7fffdcfc5738 error 4

This patch fixes it so it shows:

openvpn[424]: ERROR: --tls-crypt requires AES-256-CTR support.
openvpn[424]: Exiting due to fatal error

Trac: #825
---
 src/openvpn/tls_crypt.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c
index a227379..bda14fd 100644
--- a/src/openvpn/tls_crypt.c
+++ b/src/openvpn/tls_crypt.c
@@ -51,9 +51,7 @@ tls_crypt_init_key(struct key_ctx_bi *key, const char *key_file,
 
 struct key_type kt;
 kt.cipher = cipher_kt_get("AES-256-CTR");
-kt.cipher_length = cipher_kt_key_size(kt.cipher);
 kt.digest = md_kt_get("SHA256");
-kt.hmac_length = md_kt_size(kt.digest);
 
 if (!kt.cipher)
 {
@@ -64,6 +62,9 @@ tls_crypt_init_key(struct key_ctx_bi *key, const char *key_file,
 msg(M_FATAL, "ERROR: --tls-crypt requires HMAC-SHA-256 support.");
 }
 
+kt.cipher_length = cipher_kt_key_size(kt.cipher);
+kt.hmac_length = md_kt_size(kt.digest);
+
 crypto_read_openvpn_key(&kt, key, key_file, key_inline, key_direction,
 "Control Channel Encryption", "tls-crypt");
 }
-- 
2.7.4

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2 2/3] lz4: Rebase compat-lz4 against upstream v1.7.5

2017-02-21 Thread David Sommerseth

This rebase is done using the new lz4-rebaser.sh tool

The lz4 v1.7.5 is based on commit 7bb64ff2b69a9f8367 in
git://github.com/lz4/lz4

Signed-off-by: David Sommerseth 
---
 src/compat/compat-lz4.c | 830 +++-
 src/compat/compat-lz4.h | 377 ++
 2 files changed, 630 insertions(+), 577 deletions(-)

diff --git a/src/compat/compat-lz4.c b/src/compat/compat-lz4.c
index 5855ca1..723157d 100644
--- a/src/compat/compat-lz4.c
+++ b/src/compat/compat-lz4.c
@@ -1,6 +1,16 @@
+/* This file has been backported by dev-tools/lz4-rebaser.sh
+ * from upstream lz4 commit 7bb64ff2b69a9f8367de (v1.7.5)
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#elif defined(_MSC_VER)
+#include "config-msvc.h"
+#endif
+
+#ifdef NEED_COMPAT_LZ4
 /*
LZ4 - Fast LZ compression algorithm
-   Copyright (C) 2011-2015, Yann Collet.
+   Copyright (C) 2011-2016, Yann Collet.
 
BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
 
@@ -28,19 +38,12 @@
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
You can contact the author at :
-   - LZ4 source repository : https://github.com/Cyan4973/lz4
-   - LZ4 public forum : https://groups.google.com/forum/#!forum/lz4c
+- LZ4 homepage : http://www.lz4.org
+- LZ4 source repository : https://github.com/lz4/lz4
 */
 
-#ifdef HAVE_CONFIG_H
-#include "config.h"
-#elif defined(_MSC_VER)
-#include "config-msvc.h"
-#endif
 
-#ifdef NEED_COMPAT_LZ4
-
-/**
+/*-
 *  Tuning parameters
 **/
 /*
@@ -48,7 +51,9 @@
  * Select how default compression functions will allocate memory for their 
hash table,
  * in memory stack (0:default, fastest), or in memory heap (1:requires 
malloc()).
  */
-#define HEAPMODE 0
+#ifndef HEAPMODE
+#  define HEAPMODE 0
+#endif
 
 /*
  * ACCELERATION_DEFAULT :
@@ -57,9 +62,31 @@
 #define ACCELERATION_DEFAULT 1
 
 
-/**
+/*-
 *  CPU Feature Detection
 **/
+/* LZ4_FORCE_MEMORY_ACCESS
+ * By default, access to unaligned memory is controlled by `memcpy()`, which 
is safe and portable.
+ * Unfortunately, on some target/compiler combinations, the generated assembly 
is sub-optimal.
+ * The below switch allow to select different access method for improved 
performance.
+ * Method 0 (default) : use `memcpy()`. Safe and portable.
+ * Method 1 : `__packed` statement. It depends on compiler extension (ie, not 
portable).
+ *This method is safe if your compiler supports it, and 
*generally* as fast or faster than `memcpy`.
+ * Method 2 : direct access. This method is portable but violate C standard.
+ *It can generate buggy code on targets which generate assembly 
depending on alignment.
+ *But in some circumstances, it's the only known way to get the 
most performance (ie GCC + ARMv6)
+ * See 
https://fastcompression.blogspot.fr/2015/08/accessing-unaligned-memory.html for 
details.
+ * Prefer these methods in priority order (0 > 1 > 2)
+ */
+#ifndef LZ4_FORCE_MEMORY_ACCESS   /* can be defined externally, on command 
line for example */
+#  if defined(__GNUC__) && ( defined(__ARM_ARCH_6__) || 
defined(__ARM_ARCH_6J__) || defined(__ARM_ARCH_6K__) || 
defined(__ARM_ARCH_6Z__) || defined(__ARM_ARCH_6ZK__) || 
defined(__ARM_ARCH_6T2__) )
+#define LZ4_FORCE_MEMORY_ACCESS 2
+#  elif defined(__INTEL_COMPILER) || \
+  (defined(__GNUC__) && ( defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) 
|| defined(__ARM_ARCH_7R__) || defined(__ARM_ARCH_7M__) || 
defined(__ARM_ARCH_7S__) ))
+#define LZ4_FORCE_MEMORY_ACCESS 1
+#  endif
+#endif
+
 /*
  * LZ4_FORCE_SW_BITCOUNT
  * Define this parameter if your target system or compiler does not support 
hardware bit count
@@ -69,13 +96,14 @@
 #endif
 
 
-/**
-*  Includes
+/*-
+*  Dependency
 **/
 #include "compat-lz4.h"
+/* see also "memory routines" below */
 
 
-/**
+/*-
 *  Compiler Options
 **/
 #ifdef _MSC_VER/* Visual Studio */
@@ -84,19 +112,16 @@
 #  pragma warning(disable : 4127)/* disable: C4127: conditional 
expression is constant */
 #  pragma warning(disable : 4293)/* disable: C4293: too large shift 
(32-bits) */
 #else
-#  if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)   /* C99 */
-#if defined(__GNUC__) || defined(__clang__)
-#  define FORCE_INLINE static inline __attribute__((always_inline))
-#else
-#  define FORCE_INLINE static inline
-#endif
+#  if defined(__GNUC__) || defined(__clang__)
+#define FORCE_INLINE static inline __attribute__((always_inline))
+#  elif defined(__cplusplus) || (defined(__STDC_VERSI

[Openvpn-devel] [PATCH v2 1/3] dev-tools: lz4-rebaser tool carried a typo

2017-02-21 Thread David Sommerseth

The HAVE_CONFIG_H block which gets added to compat-lz4.c was
missing a # before the first ifdef statement.

Signed-off-by: David Sommerseth 
---
 dev-tools/lz4-rebaser.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dev-tools/lz4-rebaser.sh b/dev-tools/lz4-rebaser.sh
index 8a45ffd..4ef4de8 100755
--- a/dev-tools/lz4-rebaser.sh
+++ b/dev-tools/lz4-rebaser.sh
@@ -50,7 +50,7 @@ echo "* Porting upstream lz4.c to compat-lz4.c"
 /* This file has been backported by $0
  * from upstream lz4 commit $lz4_commit ($lz4_tag)
  */
-ifdef HAVE_CONFIG_H
+#ifdef HAVE_CONFIG_H
 #include "config.h"
 #elif defined(_MSC_VER)
 #include "config-msvc.h"
-- 
2.11.0


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2 3/3] Replace deprecated LZ4 function

2017-02-21 Thread David Sommerseth

From: Christian Hesse 

The LZ4 function LZ4_compress_limitedOutput() is deprecated, compiler
gives warning:

warning: ‘LZ4_compress_limitedOutput’ is deprecated: use
LZ4_compress_default() instead

The new function LZ4_compress_default() appeared in r129 (1.7.0), so
replace the function there.

Signed-off-by: Christian Hesse 
---
 src/openvpn/comp-lz4.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/openvpn/comp-lz4.c b/src/openvpn/comp-lz4.c
index e1f83e7..41b7d1b 100644
--- a/src/openvpn/comp-lz4.c
+++ b/src/openvpn/comp-lz4.c
@@ -87,7 +87,11 @@ do_lz4_compress(struct buffer *buf,
 return false;
 }
 
+#if defined LZ4_VERSION_NUMBER && LZ4_VERSION_NUMBER >= 10700
+zlen = LZ4_compress_default((const char *)BPTR(buf), (char 
*)BPTR(work), BLEN(buf), zlen_max );
+#else
 zlen = LZ4_compress_limitedOutput((const char *)BPTR(buf), (char 
*)BPTR(work), BLEN(buf), zlen_max );
+#endif
 
 if (zlen <= 0)
 {
-- 
2.11.0


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2 0/3] LZ4 updates

2017-02-21 Thread David Sommerseth

This is an updated LZ4 patch series.  It fixes a silly bug
which sneaked into the lz4-rebaser.sh tool, rebases LZ4 to
upstream lz4-1.7.5 and updates our LZ4 usage to not use a
deprecated API.

This patch-set replaces the previous [1] LZ4 update series.


[1] Message-Id: <1481833246-32507-1-git-send-email-dav...@openvpn.net>



Christian Hesse (1):
  Replace deprecated LZ4 function

David Sommerseth (2):
  dev-tools: lz4-rebaser tool carried a typo
  lz4: Rebase compat-lz4 against upstream v1.7.5

 dev-tools/lz4-rebaser.sh |   2 +-
 src/compat/compat-lz4.c  | 830 ++-
 src/compat/compat-lz4.h  | 377 +
 src/openvpn/comp-lz4.c   |   4 +
 4 files changed, 635 insertions(+), 578 deletions(-)

-- 
2.11.0


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system

2017-02-21 Thread Gert Doering

Hi,

following up on the thread starter...

On Wed, Jan 18, 2017 at 04:43:22PM +0100, Thomas Schäfer wrote:
> This works perfectly as long the client has still an IPv4-connection.
> 
> But in case of an IPv6-only-client (not system-wide disabled, just not 
> getting IPv4-addresses by the ISP, e.g. eduroam-IPv6) the client doesn't 
> set the IPv4-default route, since it can not find the old one.

This has been fixed (thanks, Antonio), and the fix will be in the upcoming
2.4.1 release - no fixed date has been set but "in the next few weeks" or so.

Thanks for reporting this application silliness :-)

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: fix redirect-gateway behaviour when an IPv4 default route does not exist

2017-02-21 Thread Gert Doering

ACK.

Verified the problematic behaviour (connected from a FreeBSD 11 system
without an IPv4 default route to a v6-transport VPN server, and it refused
"redirect-gateway", with or without "def1") - and with the patch, it does
the expected thing.

Also, stared at the code :-)

Your patch has been applied to the master and release/2.4 branch.

commit 14670a9d654be48f92b58ac47e6f74d3dcfe1733 (master)
commit 5340f56b62c9fe7ad892e815029321f378660714 (release/2.4)
Author: Antonio Quartulli
Date:   Fri Jan 20 00:25:18 2017 +0800

 fix redirect-gateway behaviour when an IPv4 default route does not exist

 Signed-off-by: Antonio Quartulli 
 Acked-by: Gert Doering 
 Message-Id: <20170119162518.31752-...@unstable.cc>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13905.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Updates to the git repositories

2017-02-21 Thread David Sommerseth

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hi,

Since the early days of the OpenVPN git era, we have done pushes
to both a stable (openvpn.git) repository and a testing
(openvpn-testing.git) repository.  In the early days, this made
a lot of sense.

But life moves on, evolves and things changes.

Since the v2.3 release we have not really used any of the
"features" we used the openvpn-testing.git repository for.  In
fact, openvpn.git and openvpn-testing.git have in most cases
been a replica of the master branch.  So this makes little sense
to carry on further.

In the developers meeting of December 21, 2016 [1] we decided to
decommission the openvpn-testing.git ... the plan of "early
January 2017" have dragged, but this happens now.

As of today we have stopped pushing new commits to
openvpn-testing.git.  In the coming weeks, that repository will
be completely deleted from sourceforge.net.

To ensure all can verify that the repository content have not
been tampered with, we do push the OpenVPN code to three
different public repositories (in addition to our own private
repositories)

  - github
git://github.com/OpenVPN/openvpn.git
https://github.com/OpenVPN/openvpn.git

  - gitlab
https://gitlab.com/openvpn/openvpn.git

  - sourceforge.net
git://git.code.sf.net/p/openvpn/openvpn
https://git.code.sf.net/p/openvpn/openvpn

The master branch and all the release/* branches should have the
same commit reference, as well as all tags should be identical.

In addition, all the git pushes I do are also GPG signed git
commits.  My git signing key is the same I use in my e-mails to
this mailing list (0x57DB9DAB613B8DA1).  To verify the GPG
signatures, you can add --show-signature to 'git log' and
'git show'.  In addition you can use 'git verify-commit' to
verify specific commits.


- -- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYrFVyAAoJEIbPlEyWcf3yQQYP/2I2IhT3fXhSZCAKjrfZfKah
1ymuSGfJMeef+PRpmPn5kzz1b4swOib73oBB+j8pPC6NSjjoomNnS19GgVt6yhqg
Rnz99MLMts2Mmk2cgmL2kKPShKk8Hh09cDTok7QOC36KfSzy1vpoerhDHaMP1jt0
DNA0cm8CgVd11AYt/YWtl8Yw2c07jJaXAomVMteejIY8FKtyk9QH6cVNk3/BLb6L
bwbNf6wjESNGWm7dSVvA+pNKMnCU9okefYlV/CAg+sraKZfWp+5wdyP4rY+WX90b
io0HsmjNVvChTBuHgGVJRiUbxDgr83aVSIVsfWZIesMA/ciq8FgQJwssLoVZPjna
Bzip3BFA7YwmSfa1T2DcOiYI7IfpsdNFL+AvdSqsTgdo2K/dlMbW3u8/dK9PHNLQ
+CFcXPmJBJYY6D7o+t8B08/N0KypPBwu1+9tkoiemCkF4u16Fhiy5debnVGpOeCL
F+TJAzClNjZsxByuWMYWf1AEcU6S8q7x77Mhj/shglXLxHzq3CcDsR45cb8nB3Jt
mQBPgGdUAM2mtBeFxSreL+dv8Tw7e05GcubTLeN6t78D2xvXZyhLxU7z2GBHJ98V
AkXmK9gO1yTSGMpSdIscZWc++M4g0za5O4bOjtv0X9GX/QlT0sk/WunBRewqzrNJ
yZKgVAfRh/hQUVfNTwzC
=XDRY
-END PGP SIGNATURE-

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: dev-tools: Simple tool wihch automates rebasing LZ4 compat library

2017-02-21 Thread Gert Doering

ACK.

Your patch has been applied to the master branch.

Some comments:

 - I'm not putting this into release/2.4 branch, as we're only ever going
   to use it in master - lz4 changes get applied to master, and then
   cherrypicked to other branches.

 - the sed statement has been fix-on-commit'ed as discussed on the list

 - a small grammatical mistake in the comment added to the newly imported
   compat-lz4.c has been fixed ("This file *has* been...")

 - typo in the commit message fixed ("wihch")

commit fce9d75b2c44c354457522643eddc914e41f2d84
Author: David Sommerseth
Date:   Wed Jan 25 21:53:02 2017 +0100

 dev-tools: Simple tool which automates rebasing LZ4 compat library

 Signed-off-by: David Sommerseth 
 Acked-by: Gert Doering 
 Message-Id: <20170125205302.23069-1-dav...@openvpn.net>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13962.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Topics for the upcoming (Wednesday, 22nd February 2016) community meeting

2017-02-21 Thread Samuli Seppänen

Hi,

We're going to have an IRC meeting on Wednesday 22nd February 2016. The
meeting begins at 20:00 CET (19:00 UTC) on #openvpn-meeting 
irc.freenode.net. You do not have to be logged in to Freenode to join
the channel.

Current topic list along with basic information is here:



If you have any other things you'd like to bring up, respond to this
mail, send me mail privately or add them to the list yourself.

In case you can't attend the meeting, please feel free to make comments
on the topics by responding to this email or to the summary email sent
after the meeting. Whenever possible, we'll also respond to existing,
related email threads.

--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

Re: [Openvpn-devel] build against openssl 1.1.0

Re: [Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

Re: [Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

Re: [Openvpn-devel] [RFC PATCH v1 09/15] OpenSSL: don't use direct access to the internal of X509_STORE_CTX

[Openvpn-devel] [PATCH applied] Re: dev-tools: lz4-rebaser tool carried a typo

Re: [Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

[Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

[Openvpn-devel] [PATCH v2 2/3] lz4: Rebase compat-lz4 against upstream v1.7.5

[Openvpn-devel] [PATCH v2 1/3] dev-tools: lz4-rebaser tool carried a typo

[Openvpn-devel] [PATCH v2 3/3] Replace deprecated LZ4 function

[Openvpn-devel] [PATCH v2 0/3] LZ4 updates

Re: [Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system

[Openvpn-devel] [PATCH applied] Re: fix redirect-gateway behaviour when an IPv4 default route does not exist

[Openvpn-devel] Updates to the git repositories

[Openvpn-devel] [PATCH applied] Re: dev-tools: Simple tool wihch automates rebasing LZ4 compat library

[Openvpn-devel] Topics for the upcoming (Wednesday, 22nd February 2016) community meeting

17 matches

Site Navigation

Mail list logo

Footer information