[Openvpn-devel] [PATCH 1/1] replace deprecated LZ4 function

2016-12-15 Thread Christian Hesse
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

So replace the function.

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

diff --git a/src/openvpn/comp-lz4.c b/src/openvpn/comp-lz4.c
index 6b7c49b..90feaa5 100644
--- a/src/openvpn/comp-lz4.c
+++ b/src/openvpn/comp-lz4.c
@@ -87,7 +87,7 @@ do_lz4_compress(struct buffer *buf,
 return false;
 }
 
-zlen = LZ4_compress_limitedOutput((const char *)BPTR(buf), (char 
*)BPTR(work), BLEN(buf), zlen_max );
+zlen = LZ4_compress_default((const char *)BPTR(buf), (char 
*)BPTR(work), BLEN(buf), zlen_max );
 
 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


Re: [Openvpn-devel] [PATCH 1/1] replace deprecated LZ4 function

2016-12-15 Thread David Woodhouse
On Thu, 2016-12-15 at 14:26 +0100, Christian Hesse wrote:
> -    zlen = LZ4_compress_limitedOutput((const char *)BPTR(buf), (char 
> *)BPTR(work), BLEN(buf), zlen_max );
> +    zlen = LZ4_compress_default((const char *)BPTR(buf), (char 
> *)BPTR(work), BLEN(buf), zlen_max );

You might want to do that conditionally. Some platforms might still be
using versions of liblz4 older than r129, where LZ4_compress_default()
was introduced.

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/01d40d8

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic 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] ngx_stream_ssl_preread_module does not seem to extract the server_name when connecting with openconnect

2016-12-15 Thread Thomas Glanzmann
Hello Roman,

> You can try logging $ssl_preread_server_name in access_log.

thank you. It seems that nginx is not able to extract the server_name
from openconnect correctly:

2a01:598:8181:37ef:95e1:682:4c98:449e - [15/Dec/2016:17:45:57 +0100] ""

When I connect with a browser:

2a01:598:8181:37ef:95e1:682:4c98:449e - [15/Dec/2016:17:46:20 +0100] 
"vpn.gmvl.de"

This seems to be one problem. And another problem seems that backend
communication between nginx and ocserv using the proxy protocol.

Here is tcpdump of the openconnect ssl handshake with nginx:

https://thomas.glanzmann.de/tmp/openconnect_sni.pcap

I'm using the command line 'openconnect vpn.gmvl.de'.

Cheers,
Thomas

--
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] Coding style clean-up ... phase 1

2016-12-15 Thread Selva Nair
On Thu, Dec 15, 2016 at 8:00 AM, David Sommerseth <
open...@sf.lists.topphemmelig.net> wrote:

> > The only issue I noticed is that some functions, for loops and switch
> > statements have their opening braces on the same line
> > ssl.c line 272, tun.c line 697 and many such in the several files.
> > (try grep ") {$"  *.c).
> >
> > Probably needed nl_switch_brace, nl_fcall_brace etc in the config --
> > urgh.. Too many options is a blessing and bane at the same time..
>
> Agreed.  I think that we can do some minor reformatting changes later on
> if we decide to change some more options.  Those reformatting changes
> will most likely not be as invasive as this one has been.
>

There are also some multi-line comments with closing "*/" not on a line by
itself.

If we want to fix any of this I think this is the time -- massive
reformatting is not something to be done often.


> > This is not a show stopper for me. Could be handled manually in future
> > edits when code in the vicinity is touched..
>
> I will now write a new script which patch contributors should run
> against modified files before committing and submitting.  This should
> hopefully make it better in the long run.  But with that in mind, we
> will need to re-run the reformat-all.sh script each time we decide to
> modify uncrustify options.


We have to be cautious here. Running uncrustify on is not something we
should do frequently -- I thought this was a once in a lifetime
reformatting to be followed by some self-imposed discipline for future
patches guided by the CodeStyle page.

First, uncrustify is not idempotent, although running two or three times
appears to make the source settle into an invariant form. Sometimes
multiple runs slightly messes up some otherwise good formatting.  Secondly,
its an actively developed code so behaviour could change. In fact they
already fixed the segfault bug that I had reported upstream.

So I'd be wary of adopting a policy that patch submission be preceded by an
uncrustify run.

Selva
--
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] Don't reopen tun if cipher changes

2016-12-15 Thread Steffan Karger
When the pulled options change, OpenVPN will attempt to reopen the tun
device.  That might fail if the process has already dropper privileges,
and is not needed unless the tun MTU is changed.  This patch therefore
ignores the cipher value for the digest if a fixed tun-mtu is used.

Additionally, this patch changes the md_ctx_update() call to include the
trailing zero byte of each option, to make sure that parsing "foo,bar"
results in a different hash than "foobar".  (Sorry for not catching that
during the review...)

Trac: #761

Signed-off-by: Steffan Karger 
---
 src/openvpn/push.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/src/openvpn/push.c b/src/openvpn/push.c
index 34c65c4..674efeb 100644
--- a/src/openvpn/push.c
+++ b/src/openvpn/push.c
@@ -677,17 +677,22 @@ process_incoming_push_request(struct context *c)
 #endif /* if P2MP_SERVER */
 
 static void
-push_update_digest(md_ctx_t *ctx, struct buffer *buf)
+push_update_digest(md_ctx_t *ctx, struct buffer *buf, const struct options 
*opt)
 {
 char line[OPTION_PARM_SIZE];
 while (buf_parse(buf, ',', line, sizeof(line)))
 {
 /* peer-id might change on restart and this should not trigger 
reopening tun */
-if (strstr(line, "peer-id ") != line)
+if (strcmp(line, "peer-id ") == 0)
 {
-md_ctx_update(ctx, (const uint8_t *) line, strlen(line));
+continue;
 }
-}
+if (strcmp(line, "cipher ") == 0 && !opt->ce.tun_mtu_defined)
+{
+continue;
+}
+   }
+md_ctx_update(ctx, (const uint8_t *) line, strlen(line)+1);
 }
 
 int
@@ -730,7 +735,8 @@ process_incoming_push_msg(struct context *c,
option_types_found,
c->c2.es))
 {
-push_update_digest(>c2.pulled_options_state, _orig);
+push_update_digest(>c2.pulled_options_state, _orig,
+   >options);
 switch (c->options.push_continuation)
 {
 case 0:
-- 
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 1/2] lz4: Rebase compat-lz4 against upstream v1.7.4.2

2016-12-15 Thread David Sommerseth
Rebase process is based on description in commit 46e4b6639a950c56.

The lz4 v1.7.4.2 is based on commit 018ddf799917ee5c68b5 in
git://github.com/lz4/lz4

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

diff --git a/src/compat/compat-lz4.c b/src/compat/compat-lz4.c
index 5855ca1..319abee 100644
--- a/src/compat/compat-lz4.c
+++ b/src/compat/compat-lz4.c
@@ -1,6 +1,6 @@
 /*
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 +28,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 +41,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 +52,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 +86,14 @@
 #endif
 
 
-/**
-*  Includes
+/*-
+*  Dependency
 **/
 #include "compat-lz4.h"
+/* see also "memory routines" below */
 
 
-/**
+/*-
 *  Compiler Options
 **/
 #ifdef _MSC_VER/* Visual Studio */
@@ -84,19 +102,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_VERSION__) && 
(__STDC_VERSION__ >= 199901L) /* C99 */)
+#define FORCE_INLINE static inline
 #  else
 #define FORCE_INLINE static
-#  endif   /* __STDC_VERSION__ */
+#  endif
 #endif  /* _MSC_VER */
 
-/* 

[Openvpn-devel] [PATCH 0/2] LZ4 updates

2016-12-15 Thread David Sommerseth
This patch set is rebasing the LZ4 compat library to the latest upstream
LZ4 release (v1.7.4.2).  This library is only used if ./configure cannot
find a system LZ4 library.

In addition, I've included Christian Hesse's patch he already sent to the
mailing list as we should review those two combined.  His patch will ensure
we will be able to build against LZ4 libraries older than lz4-r129.

But ... should we also consider to build against compat-lz4 if a too old
library is found?  Too old perpahs should be related to if the
LZ4_VERSION_NUMBER macro can be found or not.  The problem however with
static linking is if the system upgrades from r131 (not carrying that macro)
to a future version v1.8, then OpenVPN would not benefit from the newer
system library.  This gets critical if there are some security patches to
the LZ4 library, which would then require a new build of OpenVPN.

There is also another potential issue with the current approach, if we link
against r129 or older ... the code will be using
LZ4_compress_limitedOutput().  If the system library is upgraded to a newer
upstream version which finally removes LZ4_compress_limitedOutput(), OpenVPN
will break.

One way to get around this, which is not trivial and causes alot more code
to be added, is to always build and link the compat-lz4 library under its
own name space.  Then not to do a dynamic linking against liblz4, but rather
try to load it at runtime and probe it.  Once the newest version is
determined, the proper function pointers are set up, pointing at the LZ4
version we prefer - either our own compat-lz4 or the system wide liblz4. But
I am far from convinced this is a good or reasonable approach for this part
of the code.


Christian Hesse (1):
  replace deprecated LZ4 function

David Sommerseth (1):
  lz4: Rebase compat-lz4 against upstream v1.7.4.2

 src/compat/compat-lz4.c | 820 ++--
 src/compat/compat-lz4.h | 377 ++
 src/openvpn/comp-lz4.c  |   4 +
 3 files changed, 623 insertions(+), 578 deletions(-)


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc


--
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 2/2] replace deprecated LZ4 function

2016-12-15 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 6b7c49b..a6ce4f7 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)
 {
-- 
1.8.3.1


--
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] Don't reopen tun if cipher changes

2016-12-15 Thread David Sommerseth
On 15/12/16 19:52, Steffan Karger wrote:
> When the pulled options change, OpenVPN will attempt to reopen the tun
> device.  That might fail if the process has already dropper privileges,
> and is not needed unless the tun MTU is changed.  This patch therefore
> ignores the cipher value for the digest if a fixed tun-mtu is used.
> 
> Additionally, this patch changes the md_ctx_update() call to include the
> trailing zero byte of each option, to make sure that parsing "foo,bar"
> results in a different hash than "foobar".  (Sorry for not catching that
> during the review...)
> 
> Trac: #761
> 
> Signed-off-by: Steffan Karger 
> ---
>  src/openvpn/push.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/src/openvpn/push.c b/src/openvpn/push.c
> index 34c65c4..674efeb 100644
> --- a/src/openvpn/push.c
> +++ b/src/openvpn/push.c
> @@ -677,17 +677,22 @@ process_incoming_push_request(struct context *c)
>  #endif /* if P2MP_SERVER */
>  
>  static void
> -push_update_digest(md_ctx_t *ctx, struct buffer *buf)
> +push_update_digest(md_ctx_t *ctx, struct buffer *buf, const struct options 
> *opt)
>  {
>  char line[OPTION_PARM_SIZE];
>  while (buf_parse(buf, ',', line, sizeof(line)))
>  {
>  /* peer-id might change on restart and this should not trigger 
> reopening tun */
> -if (strstr(line, "peer-id ") != line)
> +if (strcmp(line, "peer-id ") == 0)

Are you sure about this strcmp()?  I'd expect line to contain
"peer-id 1" or something like that ... so the result would be 49 (or
anything not 0)  strncmp(line, "peer-id ", 8) would provide a match
though.

>  {
> -md_ctx_update(ctx, (const uint8_t *) line, strlen(line));
> +continue;
>  }
> -}
> +if (strcmp(line, "cipher ") == 0 && !opt->ce.tun_mtu_defined)

Same as above.


-- 
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 v2] auth-gen-token: Hardening memory cleanup on auth-token failuers

2016-12-15 Thread David Sommerseth
[lets try unencrypted this time.]

On 15/12/16 22:52, Steffan Karger wrote:
> Hi,
> 
> On 15 December 2016 at 13:22, David Sommerseth  wrote:
>> Further improve the memory management when a clients --auth-token
>> fails the server side token authentication enabled via --auth-gen-token.
>>
>> v2 - Add ASSERT() if base64 encoding of token fails
> 
> This will need rebasing because of the reformatting.
> 
>> @@ -1255,24 +1269,11 @@ verify_user_pass(struct user_pass *up, struct 
>> tls_multi *multi,
>>   /* The token should be longer than the input when
>> * being base64 encoded
>> */
>> - if( openvpn_base64_encode(tok, AUTH_TOKEN_SIZE,
>> ->auth_token) < AUTH_TOKEN_SIZE)
>> -   {
>> - msg(D_TLS_ERRORS, "BASE64 encoding of token failed. "
>> -  "No auth-token will be activated now");
>> [...]
>> +  ASSERT(openvpn_base64_encode(tok, AUTH_TOKEN_SIZE,
>> +   >auth_token) < 
>> AUTH_TOKEN_SIZE);
> 
> Uhm, I think the < should be a > now?
> 

*facepalm*

I was completely sure I had tested it.  I really did run tests.  I just
ran the server and client on the opposite hosts.  So the VM which had
not been updated which should run the client ran the server mode instead
... thus no issues :/

I'll send a v3 patch now.

-- 
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


[Openvpn-devel] [PATCH v3] auth-gen-token: Hardening memory cleanup on auth-token failuers

2016-12-15 Thread David Sommerseth
Further improve the memory management when a clients --auth-token
fails the server side token authentication enabled via --auth-gen-token.

v2 - Add ASSERT() if base64 encoding of token fails
v3 - Use proper boolean logic in ASSERT()

Signed-off-by: David Sommerseth 
---
 src/openvpn/ssl_verify.c | 45 +++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index 4328828..d661473 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -1108,6 +1108,21 @@ verify_user_pass_management (struct tls_session 
*session, const struct user_pass
 }
 #endif
 
+/**
+ *  Wipes the authentication token out of the memory, frees and cleans up 
related buffers and flags
+ *
+ *  @param multi  Pointer to a multi object holding the auth_token variables
+ */
+static void
+wipe_auth_token(struct tls_multi *multi)
+{
+  secure_memzero (multi->auth_token, AUTH_TOKEN_SIZE);
+  free (multi->auth_token);
+  multi->auth_token = NULL;
+  multi->auth_token_sent = false;
+}
+
+
 /*
  * Main username/password verification entry point
  */
@@ -1157,6 +1172,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
   /* Ensure that the username has not changed */
   if (!tls_lock_username(multi, up->username))
 {
+  wipe_auth_token(multi);
   ks->authenticated = false;
   goto done;
 }
@@ -1168,6 +1184,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
   && (multi->auth_token_tstamp + session->opt->auth_token_lifetime) < 
now)
 {
   msg (D_HANDSHAKE, "Auth-token for client expired\n");
+  wipe_auth_token(multi);
   ks->authenticated = false;
   goto done;
 }
@@ -1176,10 +1193,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
   if (memcmp_constant_time(multi->auth_token, up->password,
  strlen(multi->auth_token)) != 0)
 {
-  secure_memzero (multi->auth_token, AUTH_TOKEN_SIZE);
-  free (multi->auth_token);
-  multi->auth_token = NULL;
-  multi->auth_token_sent = false;
+  wipe_auth_token(multi);
   ks->authenticated = false;
   tls_deauthenticate (multi);
 
@@ -1255,24 +1269,11 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
  /* The token should be longer than the input when
* being base64 encoded
*/
- if( openvpn_base64_encode(tok, AUTH_TOKEN_SIZE,
->auth_token) < AUTH_TOKEN_SIZE)
-   {
- msg(D_TLS_ERRORS, "BASE64 encoding of token failed. "
-  "No auth-token will be activated now");
- if (multi->auth_token)
-   {
- secure_memzero (multi->auth_token, AUTH_TOKEN_SIZE);
- free (multi->auth_token);
- multi->auth_token = NULL;
-   }
-   }
- else
-   {
- multi->auth_token_tstamp = now;
- dmsg (D_SHOW_KEYS, "Generated token for client: %s",
-multi->auth_token);
-   }
+  ASSERT(openvpn_base64_encode(tok, AUTH_TOKEN_SIZE,
+   >auth_token) > AUTH_TOKEN_SIZE);
+  multi->auth_token_tstamp = now;
+  dmsg (D_SHOW_KEYS, "Generated token for client: %s",
+multi->auth_token);
}
 
   if ((session->opt->ssl_flags & SSLF_USERNAME_AS_COMMON_NAME))
-- 
1.8.3.1


--
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] man page --proto needs info on udp6/tcp6 in OpenVPN 2.4

2016-12-15 Thread Matthias Andree
see Subject. There's a related Trac-ker item against 2.3:




--
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] CFT: OpenVPN 2.4 port update for FreeBSD

2016-12-15 Thread Matthias Andree
Greetings,

I've put up an OpenVPN 2.4-rc1 port for FreeBSD up for testing.

Get it from https://people.freebsd.org/~mandree/openvpn-2.4.r1-v1.tar.xz

Or review the diff at https://reviews.freebsd.org/D8813

Cheers,
Matthias







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] Don't reopen tun if cipher changes

2016-12-15 Thread Steffan Karger
Hi,

On 15 December 2016 at 20:49, David Sommerseth
 wrote:
> On 15/12/16 19:52, Steffan Karger wrote:
>> -if (strstr(line, "peer-id ") != line)
>> +if (strcmp(line, "peer-id ") == 0)
>
> Are you sure about this strcmp()?  I'd expect line to contain
> "peer-id 1" or something like that ... so the result would be 49 (or
> anything not 0)  strncmp(line, "peer-id ", 8) would provide a match
> though.

Hrmpf, you're absolutely right.  That's what I get for rushing out a
patch.  I'll send a v2 shortly.

-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] [PATCH 0/2] LZ4 updates

2016-12-15 Thread David Woodhouse
On Thu, 2016-12-15 at 21:20 +0100, David Sommerseth wrote:
> 
> There is also another potential issue with the current approach, if we link
> against r129 or older ... the code will be using
> LZ4_compress_limitedOutput().  If the system library is upgraded to a newer
> upstream version which finally removes LZ4_compress_limitedOutput(), OpenVPN
> will break.

Unless upstream is doing insane things and the distributions are
failing to do their job and catch it, removing a function would require
changing the soname; it could no longer be liblz4.so.1.

If your binary package requires liblz4.so.1 then it needs to be
present. That's always been the case. The existence of *another*
library, even if it has a similar name like liblz4.so.2, is utterly
irrelevant. There's no *new* problem here.


--
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] Don't reopen tun if cipher changes

2016-12-15 Thread Steffan Karger
When the pulled options change, OpenVPN will attempt to reopen the tun
device.  That might fail if the process has already dropper privileges,
and is not needed unless the tun MTU is changed.  This patch therefore
ignores the cipher value for the digest if a fixed tun-mtu is used.

Additionally, this patch changes the md_ctx_update() call to include the
trailing zero byte of each option, to make sure that parsing "foo,bar"
results in a different hash than "foobar".  (Sorry for not catching that
during the review...)

The unit tests are a bit lame, but it secretly serves as a way to lower
the bar for adding more buffer.c unit tests.

Trac: #761

Signed-off-by: Steffan Karger 
---
v2: check for prefix properly, add unit tests for prefix check.

 src/openvpn/buffer.h   |  8 +
 src/openvpn/push.c | 15 ++---
 tests/unit_tests/openvpn/Makefile.am   |  8 -
 tests/unit_tests/openvpn/test_buffer.c | 56 ++
 4 files changed, 82 insertions(+), 5 deletions(-)
 create mode 100644 tests/unit_tests/openvpn/test_buffer.c

diff --git a/src/openvpn/buffer.h b/src/openvpn/buffer.h
index 6bd5e20..a1a130c 100644
--- a/src/openvpn/buffer.h
+++ b/src/openvpn/buffer.h
@@ -923,6 +923,14 @@ const char *string_mod_const(const char *str,
 
 void string_replace_leading(char *str, const char match, const char replace);
 
+/** Return true iff str starts with prefix */
+static inline bool
+strprefix(const char *str, const char *prefix)
+{
+return 0 == strncmp(str, prefix, strlen(prefix));
+}
+
+
 #ifdef CHARACTER_CLASS_DEBUG
 void character_class_debug(void);
 
diff --git a/src/openvpn/push.c b/src/openvpn/push.c
index 34c65c4..77adf84 100644
--- a/src/openvpn/push.c
+++ b/src/openvpn/push.c
@@ -677,17 +677,23 @@ process_incoming_push_request(struct context *c)
 #endif /* if P2MP_SERVER */
 
 static void
-push_update_digest(md_ctx_t *ctx, struct buffer *buf)
+push_update_digest(md_ctx_t *ctx, struct buffer *buf, const struct options 
*opt)
 {
 char line[OPTION_PARM_SIZE];
 while (buf_parse(buf, ',', line, sizeof(line)))
 {
 /* peer-id might change on restart and this should not trigger 
reopening tun */
-if (strstr(line, "peer-id ") != line)
+if (strprefix(line, "peer-id "))
 {
-md_ctx_update(ctx, (const uint8_t *) line, strlen(line));
+continue;
+}
+/* tun reopen only needed if cipher change can change tun MTU */
+if (strprefix(line, "cipher ") && !opt->ce.tun_mtu_defined)
+{
+continue;
 }
 }
+md_ctx_update(ctx, (const uint8_t *) line, strlen(line)+1);
 }
 
 int
@@ -730,7 +736,8 @@ process_incoming_push_msg(struct context *c,
option_types_found,
c->c2.es))
 {
-push_update_digest(>c2.pulled_options_state, _orig);
+push_update_digest(>c2.pulled_options_state, _orig,
+   >options);
 switch (c->options.push_continuation)
 {
 case 0:
diff --git a/tests/unit_tests/openvpn/Makefile.am 
b/tests/unit_tests/openvpn/Makefile.am
index 632ff58..fafe6b2 100644
--- a/tests/unit_tests/openvpn/Makefile.am
+++ b/tests/unit_tests/openvpn/Makefile.am
@@ -1,6 +1,6 @@
 AUTOMAKE_OPTIONS = foreign
 
-check_PROGRAMS = argv_testdriver
+check_PROGRAMS = argv_testdriver buffer_testdriver
 
 if ENABLE_CRYPTO
 check_PROGRAMS += tls_crypt_testdriver
@@ -21,6 +21,12 @@ argv_testdriver_SOURCES = test_argv.c mock_msg.c \
$(openvpn_srcdir)/buffer.c \
$(openvpn_srcdir)/argv.c
 
+buffer_testdriver_CFLAGS  = @TEST_CFLAGS@ -I$(openvpn_srcdir) 
-I$(compat_srcdir)
+buffer_testdriver_LDFLAGS = @TEST_LDFLAGS@ -L$(openvpn_srcdir) 
-Wl,--wrap=parse_line
+buffer_testdriver_SOURCES = test_buffer.c mock_msg.c \
+   $(openvpn_srcdir)/buffer.c \
+   $(openvpn_srcdir)/platform.c
+
 tls_crypt_testdriver_CFLAGS  = @TEST_CFLAGS@ \
-I$(openvpn_includedir) -I$(compat_srcdir) -I$(openvpn_srcdir) \
$(OPTIONAL_CRYPTO_CFLAGS)
diff --git a/tests/unit_tests/openvpn/test_buffer.c 
b/tests/unit_tests/openvpn/test_buffer.c
new file mode 100644
index 000..5d25437
--- /dev/null
+++ b/tests/unit_tests/openvpn/test_buffer.c
@@ -0,0 +1,56 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ * over a single UDP port, with support for SSL/TLS-based
+ * session authentication and key exchange,
+ * packet encryption, packet authentication, and
+ * packet compression.
+ *
+ *  Copyright (C) 2016 Fox Crypto B.V. 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that 

Re: [Openvpn-devel] [PATCH v2] auth-gen-token: Hardening memory cleanup on auth-token failuers

2016-12-15 Thread Steffan Karger
Hi,

On 15 December 2016 at 13:22, David Sommerseth  wrote:
> Further improve the memory management when a clients --auth-token
> fails the server side token authentication enabled via --auth-gen-token.
>
> v2 - Add ASSERT() if base64 encoding of token fails

This will need rebasing because of the reformatting.

> @@ -1255,24 +1269,11 @@ verify_user_pass(struct user_pass *up, struct 
> tls_multi *multi,
>   /* The token should be longer than the input when
> * being base64 encoded
> */
> - if( openvpn_base64_encode(tok, AUTH_TOKEN_SIZE,
> ->auth_token) < AUTH_TOKEN_SIZE)
> -   {
> - msg(D_TLS_ERRORS, "BASE64 encoding of token failed. "
> -  "No auth-token will be activated now");
> [...]
> +  ASSERT(openvpn_base64_encode(tok, AUTH_TOKEN_SIZE,
> +   >auth_token) < 
> AUTH_TOKEN_SIZE);

Uhm, I think the < should be a > now?

-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 1/1] replace deprecated LZ4 function

2016-12-15 Thread Christian Hesse
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 6b7c49b..a6ce4f7 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


Re: [Openvpn-devel] [PATCH] auth-gen-token: Hardening memory cleanup on auth-token failuers

2016-12-15 Thread David Sommerseth
On 15/12/16 11:05, Gert Doering wrote:
> Hi,
> 
> On Wed, Dec 14, 2016 at 10:08:25PM +0100, Steffan Karger wrote:
>> Looks good, but I think there's one more occurance you should
>> incorporate in the patch:
>>
>>   if (openvpn_base64_encode(tok, AUTH_TOKEN_SIZE,
>> >auth_token) < AUTH_TOKEN_SIZE)
> 
> Under which conditions can this ever fail?  In other words: if this
> fails, should we consider it a major programming error and ASSERT()?

It can only fail if there's a malloc() failure in
openvpn_base64_encode().  But I agree, ASSERT() is probably more
reasonable here.

I'll send a v2 patch with assert here instead.

Side track  the malloc() size calculation in base64.c:66 is, well,
interesting:

   p = s = (char *) malloc(size * 4 / 3 + 4);



-- 
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] auth-gen-token: Hardening memory cleanup on auth-token failuers

2016-12-15 Thread Gert Doering
Hi,

On Wed, Dec 14, 2016 at 10:08:25PM +0100, Steffan Karger wrote:
> Looks good, but I think there's one more occurance you should
> incorporate in the patch:
> 
>   if (openvpn_base64_encode(tok, AUTH_TOKEN_SIZE,
> >auth_token) < AUTH_TOKEN_SIZE)

Under which conditions can this ever fail?  In other words: if this
fails, should we consider it a major programming error and ASSERT()?

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 v2] auth-gen-token: Hardening memory cleanup on auth-token failuers

2016-12-15 Thread David Sommerseth
Further improve the memory management when a clients --auth-token
fails the server side token authentication enabled via --auth-gen-token.

v2 - Add ASSERT() if base64 encoding of token fails

Signed-off-by: David Sommerseth 
---
 src/openvpn/ssl_verify.c | 45 +++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index 4328828..955d522 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -1108,6 +1108,21 @@ verify_user_pass_management (struct tls_session 
*session, const struct user_pass
 }
 #endif
 
+/**
+ *  Wipes the authentication token out of the memory, frees and cleans up 
related buffers and flags
+ *
+ *  @param multi  Pointer to a multi object holding the auth_token variables
+ */
+static void
+wipe_auth_token(struct tls_multi *multi)
+{
+  secure_memzero (multi->auth_token, AUTH_TOKEN_SIZE);
+  free (multi->auth_token);
+  multi->auth_token = NULL;
+  multi->auth_token_sent = false;
+}
+
+
 /*
  * Main username/password verification entry point
  */
@@ -1157,6 +1172,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
   /* Ensure that the username has not changed */
   if (!tls_lock_username(multi, up->username))
 {
+  wipe_auth_token(multi);
   ks->authenticated = false;
   goto done;
 }
@@ -1168,6 +1184,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
   && (multi->auth_token_tstamp + session->opt->auth_token_lifetime) < 
now)
 {
   msg (D_HANDSHAKE, "Auth-token for client expired\n");
+  wipe_auth_token(multi);
   ks->authenticated = false;
   goto done;
 }
@@ -1176,10 +1193,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
   if (memcmp_constant_time(multi->auth_token, up->password,
  strlen(multi->auth_token)) != 0)
 {
-  secure_memzero (multi->auth_token, AUTH_TOKEN_SIZE);
-  free (multi->auth_token);
-  multi->auth_token = NULL;
-  multi->auth_token_sent = false;
+  wipe_auth_token(multi);
   ks->authenticated = false;
   tls_deauthenticate (multi);
 
@@ -1255,24 +1269,11 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
  /* The token should be longer than the input when
* being base64 encoded
*/
- if( openvpn_base64_encode(tok, AUTH_TOKEN_SIZE,
->auth_token) < AUTH_TOKEN_SIZE)
-   {
- msg(D_TLS_ERRORS, "BASE64 encoding of token failed. "
-  "No auth-token will be activated now");
- if (multi->auth_token)
-   {
- secure_memzero (multi->auth_token, AUTH_TOKEN_SIZE);
- free (multi->auth_token);
- multi->auth_token = NULL;
-   }
-   }
- else
-   {
- multi->auth_token_tstamp = now;
- dmsg (D_SHOW_KEYS, "Generated token for client: %s",
-multi->auth_token);
-   }
+  ASSERT(openvpn_base64_encode(tok, AUTH_TOKEN_SIZE,
+   >auth_token) < AUTH_TOKEN_SIZE);
+  multi->auth_token_tstamp = now;
+  dmsg (D_SHOW_KEYS, "Generated token for client: %s",
+multi->auth_token);
}
 
   if ((session->opt->ssl_flags & SSLF_USERNAME_AS_COMMON_NAME))
-- 
1.8.3.1


--
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] [MERGE complete] The Great Reformatting - first phase

2016-12-15 Thread David Sommerseth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Reformatting merge complete.

commit 1f004b2f06e987d73e48f7fd7b96b0b248274f58
Merge: 2417d55 81d882d
Author: David Sommerseth
Date:   Thu Dec 15 13:45:06 2016 +0100

 Merge 'reformatting' branch into master

 This concludes the first phase of The Great Reformatting project.
  
 Reviewed-by: Selva Nair 
 Acked-By: Steffan Karger 
 Message-Id: 
<3a78050c-8c18-d54e-fc37-330272de6...@sf.lists.topphemmelig.net>
 URL: 
http://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13556.html
 Signed-off-by: David Sommerseth 


- --
kind regards,

David Sommerseth

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

iQIcBAEBAgAGBQJYUpIjAAoJEIbPlEyWcf3y4SYP/AkEwyJOnZd+Opd6vezJDjsJ
tvBv66xJzg7wnwGaiqCzHd666Ltr2FSbkfdoTSDqyf1LngviNdf148K4eQ/pkFg5
gDslVSnER43HCwEHDnOBLJy8YXUFjI2+jIvdYy5ex6eNbqixwYUvOV7m7wZsrQhP
r5yv0ggbZ75Xmz8fY6GRHI+lPPEbF4yI0YiC8dQ4Vv7TJKFj6Jyrd6Vw8OggbrNV
vuDM6CWpEgkWM7yAYCSVkgllqmDTTGJ+YFGfG6l/BZx9uaxrOgnPwtzSgFPENMuQ
sLsvt3se39jnTbkwmE3fevzuCmorU6hXUK/L02jPo1utPKLS3dgDCZlwbx8h/v66
mMB5xdKeIUfEylD+yFDjHJjHsY1ax9ubcY8ujePzmZMd2GE2txCQ1a0N62iDSp+P
ec9KOnru4ca3O6Xi0VtVbpX/TjEL0KFIrvD5Y+saIEiLUVVInczXpjjHH8zScSyF
UFeLPcGBZCyfBQcIKUsFu8b454T1o3NepCCQmw3aMFIGinZCfEd55BggdhOEr9mL
qCK6fMK60b5CfdDqM+PqRGWQ1ipUxN5ZgFYfxkqVC35TMjWC8jqg5y+duPVxttGZ
yHBKL4kQm4C67oRncpefTcJBwSnsB26fiqjd6uj6H8uiQoMQJAc9dxCkPQcDt/xc
fNtN9w/TeRcRvwUw900Z
=wcKI
-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


Re: [Openvpn-devel] Coding style clean-up ... phase 1

2016-12-15 Thread David Sommerseth
On 15/12/16 06:09, Selva Nair wrote:
> 
> On Wed, Dec 14, 2016 at 4:18 PM, David Sommerseth
>  > wrote:
> 
> On 13/12/16 22:42, David Sommerseth wrote:
> >
> > Hi all,
> >
> > So the first phase of the great reformatting is on its way.  I have
> > just pushed out a reformatting branch to the following
> > repositories:
> >
> > https://github.com:OpenVPN/openvpn.git
> > https://gitlab.com:openvpn/openvpn.git
> > git://git.code.sf.net/p/openvpn/openvpn
> 
> >
> 
> An updated reformatting branch have been pushed out.  If you have
> already fetched the it, git will most likely complain as to make
> these tests flow reasonably well without cluttering the git tree
> too much we have used forced pushes on this branch.
> 
> And again, the The Great Reformatting patch is PGP signed as well,
> which can be verified with 'git log --show-signature'.  The
> signing key is 0x86CF944C9671FDF2, which is the same as this mail
> is signed with.
> 
> 
> The reformatting looks pretty good for an automated process. The result
> agrees with independently running the script on master.
> 
> The only issue I noticed is that some functions, for loops and switch
> statements have their opening braces on the same line
> ssl.c line 272, tun.c line 697 and many such in the several files.
> (try grep ") {$"  *.c).
> 
> Probably needed nl_switch_brace, nl_fcall_brace etc in the config --
> urgh.. Too many options is a blessing and bane at the same time..

Agreed.  I think that we can do some minor reformatting changes later on
if we decide to change some more options.  Those reformatting changes
will most likely not be as invasive as this one has been.

> This is not a show stopper for me. Could be handled manually in future
> edits when code in the vicinity is touched..

I will now write a new script which patch contributors should run
against modified files before committing and submitting.  This should
hopefully make it better in the long run.  But with that in mind, we
will need to re-run the reformat-all.sh script each time we decide to
modify uncrustify options.


-- 
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 1/1] replace deprecated LZ4 function

2016-12-15 Thread David Sommerseth
On 15/12/16 15:06, Christian Hesse wrote:
> 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 6b7c49b..a6ce4f7 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)
>  {
> 

This makes sense.  But I think we should do this in relation to an
update of the compat-lz4 library we also ship in OpenVPN.  I'm running
some tests now, and will submit a new mail thread which includes this
patch together with the compat-lz4.[ch] update.

This will be handled post v2.4.0 release, so we don't rush the testing
of the LZ4 support and inadvertently break anything.


-- 
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