[Openvpn-devel] [PATCH] Do some file/directory tests before really starting openvpn

[David Sommerseth]

OpenVPN can handle over 30 different files and directories, and it is easy
to misconfigure some of them.  In many situations OpenVPN will even start
running, even with a wrong file path or without the proper permissions, and
then it will complain much later on.  In some cases the error being seen at
this late point might even be difficult to relate to a configuration option.

This patch tries to catch as many of these files as soon as possible, kind of
to "smoke-test" the files and directories to avoid the most likely errors.

Trac-ticket: 73
Signed-off-by: David Sommerseth 
---
 options.c |  151 +
 1 files changed, 151 insertions(+), 0 deletions(-)

diff --git a/options.c b/options.c
index e422c0d..28296a5 100644
--- a/options.c
+++ b/options.c
@@ -52,6 +52,8 @@
 #include "configure.h"
 #include "forward.h"
 #include 
+#include 
+#include 

 #include "memdbg.h"

@@ -2592,6 +2594,152 @@ options_postprocess_mutate (struct options *o)
 }

 /*
+ *  Check file/directory sanity
+ *
+ */
+#ifndef ENABLE_SMALL  /** Expect people using the stripped down version to 
know what they do */
+
+#define CHKACC_FILE (1<<0)   /** Check for a file/directory precense */
+#define CHKACC_DIRPATH (1<<1)/** Check for directory precense where a file 
should reside */
+#define CHKACC_FILEXSTWR (1<<2)  /** If file exists, is it writable? */
+
+static bool
+check_file_access(const int type, const char *file, const int mode, const char 
*opt)
+{
+  int errcode = 0;
+
+  /* If no file configured, no errors to look for */
+  if (!file)
+  return false;
+
+  /* Is the directory path leading to the given file accessible? */
+  if (type & CHKACC_DIRPATH)
+{
+  char *fullpath = strdup(file);  /* POSIX dirname() implementaion may 
modify its arguments */
+  char *dirpath = dirname(fullpath);
+
+  if (access (dirpath, mode|X_OK) != 0)
+  errcode = errno;
+  free(fullpath);
+}
+
+  /* Is the file itself accessible? */
+  if (!errcode && (type & CHKACC_FILE) && (access (file, mode) != 0) )
+  errcode = errno;
+
+  /* If the file exists and is accessible, is it writable? */
+  if (!errcode && (type & CHKACC_FILEXSTWR) && (access (file, F_OK) == 0) )
+if (access (file, W_OK) != 0)
+  errcode = errno;
+
+  /* Scream if an error is found */
+  if( errcode > 0 )
+msg (M_NOPREFIX|M_OPTERR, "%s fails with '%s': %s",
+ opt, file, strerror(errno));
+
+  /* Return true if an error occured */
+  return (errcode != 0 ? true : false);
+}
+
+/*
+ * Sanity check of all file/dir options.  Checks that file/dir
+ * is accessible by OpenVPN
+ */
+static void
+options_postprocess_filechecks (struct options *options)
+{
+  bool errs = false;
+
+  /* ** SSL/TLS/crypto related files ** */
+#ifdef USE_SSL
+  errs |= check_file_access (CHKACC_FILE, options->dh_file, R_OK, "--dh");
+  errs |= check_file_access (CHKACC_FILE, options->ca_file, R_OK, "--ca");
+  errs |= check_file_access (CHKACC_FILE, options->ca_path, R_OK, "--capath");
+  errs |= check_file_access (CHKACC_FILE, options->cert_file, R_OK, "--cert");
+  errs |= check_file_access (CHKACC_FILE, options->extra_certs_file, R_OK,
+ "--extra-certs");
+  errs |= check_file_access (CHKACC_FILE, options->priv_key_file, R_OK,
+ "--key");
+  errs |= check_file_access (CHKACC_FILE, options->pkcs12_file, R_OK,
+ "--pkcs12");
+  if (options->ssl_flags & SSLF_CRL_VERIFY_DIR)
+errs |= check_file_access (CHKACC_FILE, options->crl_file, R_OK|X_OK,
+   "--crl-verify directory");
+  else
+errs |= check_file_access (CHKACC_FILE, options->crl_file, R_OK,
+   "--crl-verify");
+  errs |= check_file_access (CHKACC_FILE, options->tls_auth_file, R_OK,
+ "--tls-auth");
+#endif /* USE_SSL */
+#ifdef USE_CRYPTO
+  errs |= check_file_access (CHKACC_FILE, options->shared_secret_file, R_OK,
+ "--secret");
+  errs |= check_file_access (CHKACC_DIRPATH|CHKACC_FILEXSTWR,
+ options->packet_id_file, R_OK|W_OK, 
"--replay-persist");
+#endif /* USE_CRYPTO */
+
+
+  /* ** Password files ** */
+#ifdef USE_SSL
+  errs |= check_file_access (CHKACC_FILE, options->key_pass_file, R_OK,
+ "--askpass");
+#endif /* USE_SSL */
+#ifdef ENABLE_MANAGEMENT
+  errs |= check_file_access (CHKACC_FILE, options->management_user_pass, R_OK,
+ "--management user/password file");
+#endif /* ENABLE_MANAGEMENT */
+  errs |= check_file_access (CHKACC_FILE, options->auth_user_pass_file, R_OK,
+ "--auth-user-pass");
+
+
+  /* ** System related ** */
+  errs |= check_file_access (CHKACC_FILE, options->chroot_dir,
+ R_OK|X_OK, "--chroot directory");
+  errs |= check_file_access 

[Openvpn-devel] [PATCH] RFC: Improve file checking during start-up

[David Sommerseth]

From: David Sommerseth 

The following patch has been laying in my repository for some time, unsure
why it's been there for so long.  I can't see nor recall if I posted it to
this -devel list either.  If there are things I should have fixed up before
re-posting it (if this is a repost), I appologise for that.

Please review this patch.  I don't know if this is the best approach, and if
others have better ideas for solving this.

David Sommerseth (1):
  Do some file/directory tests before really starting openvpn

 options.c |  151 +
 1 files changed, 151 insertions(+), 0 deletions(-)

-- 
1.7.4.4

[Openvpn-devel] [PATCH] Fix bug after removing Linux 2.2 support

[David Sommerseth]

From: David Sommerseth 

In commit ce637abdafdc19547fc97192033a4d1703ecaf23 the Linux 2.2 support
was removed.  When this happened an extra error check was avoided which
would normally kicked in if the tun/tap device would not be available.
Instead the following line was filling the log continously:

   Thu Nov 24 22:33:15 2011 read from TUN/TAP : File descriptor in bad state 
(code=77)

This patch changes the msg() declarations to use the M_FATAL *) flag,
which will halt the execution of the program in these error sitauations.
As the program will really halt, the return declarations was also removed.

*) #define M_ERR   (M_FATAL | M_ERRNO)  (from error.h)

Signed-off-by: David Sommerseth 
---
 tun.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/tun.c b/tun.c
index 7a3b2e9..1defe58 100644
--- a/tun.c
+++ b/tun.c
@@ -1397,8 +1397,7 @@ open_tun (const char *dev, const char *dev_type, const 
char *dev_node, struct tu
*/
   if ((tt->fd = open (node, O_RDWR)) < 0)
{
- msg (M_WARN | M_ERRNO, "Note: Cannot open TUN/TAP dev %s", node);
- return;
+ msg (M_ERR, "Note: Cannot open TUN/TAP dev %s", node);
}

   /*
@@ -1441,8 +1440,7 @@ open_tun (const char *dev, const char *dev_type, const 
char *dev_node, struct tu
*/
   if (ioctl (tt->fd, TUNSETIFF, (void *) ) < 0)
{
- msg (M_WARN | M_ERRNO, "Note: Cannot ioctl TUNSETIFF %s", dev);
- return;
+ msg (M_ERR, "Note: Cannot ioctl TUNSETIFF %s", dev);
}

   msg (M_INFO, "TUN/TAP device %s opened", ifr.ifr_name);
-- 
1.7.4.4

Re: [Openvpn-devel] Snapshot openvpn-2.x-20110909-master-install.exe fails

[Gert Doering]

Hi,

On Thu, Nov 24, 2011 at 08:51:28PM +0100, Gert Doering wrote:
> So here's the patch - it compiles (MSVC on Win7), the resulting binary
> works on WinXP, and it's not too ugly - actually it removes more #ifdef's
> that it adds...
> 
> Let me know your comments.

So David found it confusing, and I agree to some extend :-) - it's
easier to see what is happening if we declare our replacement functions
as openvpn_inet_ntop() and openvpn_inet_pton() right away, instead of
having the preprocessor #define rename them on the fly.

new patch.

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
From 0d49be3449e86365364378f48393e5e2b75a1045 Mon Sep 17 00:00:00 2001
From: Gert Doering 
List-Post: openvpn-devel@lists.sourceforge.net
Date: Thu, 24 Nov 2011 21:09:36 +0100
Subject: [PATCH] work around inet_ntop/inet_pton problems for MSVC builds on
 WinXP

always use our built-in replacement functions now, even if building
on Win7 (which has inet_ntop/inet_pton in the system libraries) because
the resulting binary will then fail on WinXP.

Signed-off-by: Gert Doering 
---
 socket.c |9 -
 win32.h  |   10 ++
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/socket.c b/socket.c
index 5302eca..c8a86ea 100644
--- a/socket.c
+++ b/socket.c
@@ -3083,11 +3083,12 @@ link_socket_write_udp_posix_sendmsg (struct link_socket 
*sock,
 /*
  * inet_ntop() and inet_pton() wrap-implementations using
  * WSAAddressToString() and WSAStringToAddress() functions
+ *
+ * this is needed as long as we support running OpenVPN on WinXP
  */
 
-#ifndef _MSC_VER
 const char *
-inet_ntop(int af, const void *src, char *dst, socklen_t size)
+openvpn_inet_ntop(int af, const void *src, char *dst, socklen_t size)
 {
   struct sockaddr_storage ss;
   unsigned long s = size;
@@ -3111,7 +3112,7 @@ inet_ntop(int af, const void *src, char *dst, socklen_t 
size)
 }
 
 int
-inet_pton(int af, const char *src, void *dst)
+openvpn_inet_pton(int af, const char *src, void *dst)
 {
   struct sockaddr_storage ss;
   int size = sizeof(ss);
@@ -3134,8 +3135,6 @@ inet_pton(int af, const char *src, void *dst)
   return 0;
 }
 
-#endif
-
 int
 socket_recv_queue (struct link_socket *sock, int maxsize)
 {
diff --git a/win32.h b/win32.h
index 5b18e3c..0607cad 100644
--- a/win32.h
+++ b/win32.h
@@ -278,10 +278,12 @@ char *get_win_sys_path (void);
 
 /* call self in a subprocess */
 void fork_to_self (const char *cmdline);
-#ifndef _MSC_VER
-const char *inet_ntop(int af, const void *src, char *dst, socklen_t size);
-int inet_pton(int af, const char *src, void *st);
-#endif
+
+const char *openvpn_inet_ntop(int af, const void *src, 
+  char *dst, socklen_t size);
+int openvpn_inet_pton(int af, const char *src, void *dst);
+#define inet_ntop(af,src,dst,size) openvpn_inet_ntop(af,src,dst,size)
+#define inet_pton(af,src,dst)  openvpn_inet_pton(af,src,dst)
 
 /* Find temporary directory */
 const char *win_get_tempdir();
-- 
1.7.4.4



pgpzI8GWndwpH.pgp
Description: PGP signature

Re: [Openvpn-devel] Snapshot openvpn-2.x-20110909-master-install.exe fails

[Gert Doering]

Hi,

On Wed, Nov 09, 2011 at 02:17:09PM +0200, Samuli Seppänen wrote:
> Il 26/09/2011 15:37, Heiko Hund ha scritto:
> > On Monday 26 September 2011 14:13:30 Samuli Seppänen wrote:
> >> Ok, did as suggested for socket.c and win32.h and got the following
> >> build failure using MSVC:
> >>
> >> 
> > ---8<--
> > c:\users\samuli\openvpn-build\openvpn\win32.h(282) : 
> > error C2373: 'inet_ntop' : redefinition; different type modifiers
> > ---8<--

after discussions with Samuli and Heiko, I propose to solve this in a
different way, namely "always use our own version of inet_ntop/inet_pton,
and do not even try to keep the prototypes right on windows".

That is, I #define inet_ntop() to openvpn_inet_ntop() and inet_pton()
to openvpn_inet_pton(), and thus change all the function calls to call
our own function on "#ifdef WIN32" builds.

Trying to keep the function names and playing with prototypes didn't
lead anywhere, and trying to play with the NTDDI_VERSION defines is
far beyond the level of detail I want to know about Windows building.

So here's the patch - it compiles (MSVC on Win7), the resulting binary
works on WinXP, and it's not too ugly - actually it removes more #ifdef's
that it adds...

Let me know your comments.

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
From 853662a6d1f5ad90e8d73032cea137541f6194e2 Mon Sep 17 00:00:00 2001
From: Gert Doering 
List-Post: openvpn-devel@lists.sourceforge.net
Date: Thu, 24 Nov 2011 19:48:27 +0100
Subject: [PATCH] work around inet_ntop/inet_pton problems for MSVC builds on
 WinXP

always use our built-in replacement functions now, even if building
on Win7 (which has inet_ntop/inet_pton in the system libraries) because
the resulting binary will then fail on WinXP.

Signed-off-by: Gert Doering 
---
 socket.c |3 ---
 win32.h  |   10 ++
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/socket.c b/socket.c
index 5302eca..d91f2dc 100644
--- a/socket.c
+++ b/socket.c
@@ -3085,7 +3085,6 @@ link_socket_write_udp_posix_sendmsg (struct link_socket 
*sock,
  * WSAAddressToString() and WSAStringToAddress() functions
  */
 
-#ifndef _MSC_VER
 const char *
 inet_ntop(int af, const void *src, char *dst, socklen_t size)
 {
@@ -3134,8 +3133,6 @@ inet_pton(int af, const char *src, void *dst)
   return 0;
 }
 
-#endif
-
 int
 socket_recv_queue (struct link_socket *sock, int maxsize)
 {
diff --git a/win32.h b/win32.h
index 5b18e3c..0607cad 100644
--- a/win32.h
+++ b/win32.h
@@ -278,10 +278,12 @@ char *get_win_sys_path (void);
 
 /* call self in a subprocess */
 void fork_to_self (const char *cmdline);
-#ifndef _MSC_VER
-const char *inet_ntop(int af, const void *src, char *dst, socklen_t size);
-int inet_pton(int af, const char *src, void *st);
-#endif
+
+const char *openvpn_inet_ntop(int af, const void *src, 
+  char *dst, socklen_t size);
+int openvpn_inet_pton(int af, const char *src, void *dst);
+#define inet_ntop(af,src,dst,size) openvpn_inet_ntop(af,src,dst,size)
+#define inet_pton(af,src,dst)  openvpn_inet_pton(af,src,dst)
 
 /* Find temporary directory */
 const char *win_get_tempdir();
-- 
1.7.4.4



pgpbka05LsSML.pgp
Description: PGP signature

Re: [Openvpn-devel] Topics for today's meeting

[Alon Bar-Lev]

My build script is working as-is with cygwin, compiling native win32 binaries!

2011/11/24 Alon Bar-Lev :
> I am *VERY* impressed from cygwin jump, I must admit I have not kept
> track on this project for a long time!
> But now it is up to date with fully operational native windows tools.
> I've done some testing, and it looks like ./configure
> --host=x86_64-w64-mingw32 or i686-w64-mingw will actually work!
> I will build with dependencies now, it will take some time.
>
> 2011/11/24 Alon Bar-Lev :
>> Correction!
>> cygwin provides mingw-w64 now!!!
>> Also recent autoconf/automake/libtool.
>> So we can also cross compile using mingw.
>>
>> 2011/11/24 Alon Bar-Lev :
>>> Hello,
>>>
>>> I won't participate in sync meeting don't have the time.
>>> Anyway, for windows build.
>>> I already provide binaries for OpenVPN using mingw-w64 project, and it
>>> works fine!
>>> I use mingw-w64 for both win32 and win64 binaries, much better than
>>> old mingw project, as mingw-w64 is maintained!
>>> You can see my build system at [1][2].
>>> So mingw cross compile is supported. I would have re-written the
>>> openvpn autoconf script to clean it up and make it more standard, but
>>> current is enough to be usable.
>>>
>>> msys can be used on Windows to build not sure it worth the effort...
>>> mingw can be used with -mno-cygwin parameter, but from my experience
>>> the toolchain in cygwin are way too old to be usable.
>>>
>>> For the tap driver, I always note this... IT SHOULD BE SEPARATE MSI
>>> and SEPARATE PROJECT.
>>> There should be absolutely no dependency between openvpn release cycle
>>> and tap release cycle.
>>> It is just like wireshark and libpcap projects.
>>> OpenVPN installer can embed the tap msi and run it during installation.
>>> When tap installed, it should register its version in registry key, so
>>> openvpn may read it in order to connect (currently it is done
>>> hardcoded within openvpn).
>>>
>>> The TAP driver should be built and signed using Microsoft toolchain,
>>> there is no problem in that. There is almost a single developer for
>>> the tap driver..
>>> The usermode components may be signed on Linux using the
>>> osslsigncode[3], so actual signing is not an issue, if this is desired
>>> I can submit a patch for "make install" to sign, as I do in other
>>> projects.
>>>
>>> Most (99%) users are interested in building custom user mode component
>>> only, so there is no sense in keeping the tap driver as dependency
>>> (build and sign).
>>>
>>> Regards,
>>> Alon.
>>>
>>> [1] https://www.opensc-project.org/build/
>>> [2] https://www.opensc-project.org/build/browser
>>> [3] http://sourceforge.net/projects/osslsigncode/
>>>
>>> 2011/11/24 Samuli Seppänen 

 Hi,

 We're having an IRC meeting today, starting at 18:00 UTC on
 #openvpn-de...@irc.freenode.net. Current topic list 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.

 NOTE: It's required to use a registered Freenode IRC nickname to join
 #openvpn-devel - look here for details:

 

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

 irc freenode net: mattock

 --
 All the data continuously generated in your IT infrastructure
 contains a definitive record of customers, application performance,
 security threats, fraudulent activity, and more. Splunk takes this
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 Openvpn-devel mailing list
 Openvpn-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>>
>>
>

Re: [Openvpn-devel] [PATCH] UTF-8 X.509 distinguished names

[Alon Bar-Lev]

On Thu, Nov 24, 2011 at 1:42 PM, Heiko Hund  wrote:
> On Wednesday 23 November 2011 17:48:54 Alon Bar-Lev wrote:
>> Yes, there are many none unicode environments, and I am not sure what
>> this patch will behave in windows environment as it is SCS-2 not
>> UTF-8.

It is UCS-2 not UCS-16.

>
> I agree on the UCS-16 environment in Windows. Will post a patch for that soon,
> as I'm almost ready with one handling UCS-16 file system related stuff. It'll
> be just a small addition to that patch.
>
>> OpenVPN is also used in embedded systems, such as dd-wrt.com and other.
>> So I guess I would like to see unicode=true parameter on *NIX use
>> UTF-8, on Windows use UCS-2.
>
> Why would that be useful? Does it make a difference if scripts in a latin-1
> environment receive "j\C3\B6rn" or "jörn"? Both forms won't be recognizable
> without additional effort, while being equally harmless.

ANSI can handle j\C13\B6rn without problem, comparing displaying, altering.

>
> Regards
> Heiko
> --
> Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200
> Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
> Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe
>
> Represented by the General Partner Astaro Verwaltungs GmbH
> Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany
> Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen,
> Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
>
>
>
>

Re: [Openvpn-devel] [PATCH] UTF-8 X.509 distinguished names

[Heiko Hund]

On Wednesday 23 November 2011 17:48:54 Alon Bar-Lev wrote:
> Yes, there are many none unicode environments, and I am not sure what
> this patch will behave in windows environment as it is SCS-2 not
> UTF-8.

I agree on the UCS-16 environment in Windows. Will post a patch for that soon, 
as I'm almost ready with one handling UCS-16 file system related stuff. It'll 
be just a small addition to that patch.

> OpenVPN is also used in embedded systems, such as dd-wrt.com and other.
> So I guess I would like to see unicode=true parameter on *NIX use
> UTF-8, on Windows use UCS-2.

Why would that be useful? Does it make a difference if scripts in a latin-1 
environment receive "j\C3\B6rn" or "jörn"? Both forms won't be recognizable 
without additional effort, while being equally harmless.

Regards
Heiko
-- 
Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200
Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe
 
Represented by the General Partner Astaro Verwaltungs GmbH
Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany 
Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen,
Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen

Re: [Openvpn-devel] Topics for today's meeting

[Gert Doering]

Hi,

On Thu, Nov 24, 2011 at 10:58:50AM +0100, Jan Just Keijser wrote:
> +1 autoconf
> -9 CMake

+1 autoconf
-450 anything that requires installation of additional tools on unix systems

(I wouldn't mind if anyone were to create a cmake build environment for
windows, documents that, and commits to maintaining it for a while - but 
please do not convolute the working unix build environment we have right 
now)

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


pgp_7QPXycTZw.pgp
Description: PGP signature

Re: [Openvpn-devel] Topics for today's meeting

[Alon Bar-Lev]

I am *VERY* impressed from cygwin jump, I must admit I have not kept
track on this project for a long time!
But now it is up to date with fully operational native windows tools.
I've done some testing, and it looks like ./configure
--host=x86_64-w64-mingw32 or i686-w64-mingw will actually work!
I will build with dependencies now, it will take some time.

2011/11/24 Alon Bar-Lev :
> Correction!
> cygwin provides mingw-w64 now!!!
> Also recent autoconf/automake/libtool.
> So we can also cross compile using mingw.
>
> 2011/11/24 Alon Bar-Lev :
>> Hello,
>>
>> I won't participate in sync meeting don't have the time.
>> Anyway, for windows build.
>> I already provide binaries for OpenVPN using mingw-w64 project, and it
>> works fine!
>> I use mingw-w64 for both win32 and win64 binaries, much better than
>> old mingw project, as mingw-w64 is maintained!
>> You can see my build system at [1][2].
>> So mingw cross compile is supported. I would have re-written the
>> openvpn autoconf script to clean it up and make it more standard, but
>> current is enough to be usable.
>>
>> msys can be used on Windows to build not sure it worth the effort...
>> mingw can be used with -mno-cygwin parameter, but from my experience
>> the toolchain in cygwin are way too old to be usable.
>>
>> For the tap driver, I always note this... IT SHOULD BE SEPARATE MSI
>> and SEPARATE PROJECT.
>> There should be absolutely no dependency between openvpn release cycle
>> and tap release cycle.
>> It is just like wireshark and libpcap projects.
>> OpenVPN installer can embed the tap msi and run it during installation.
>> When tap installed, it should register its version in registry key, so
>> openvpn may read it in order to connect (currently it is done
>> hardcoded within openvpn).
>>
>> The TAP driver should be built and signed using Microsoft toolchain,
>> there is no problem in that. There is almost a single developer for
>> the tap driver..
>> The usermode components may be signed on Linux using the
>> osslsigncode[3], so actual signing is not an issue, if this is desired
>> I can submit a patch for "make install" to sign, as I do in other
>> projects.
>>
>> Most (99%) users are interested in building custom user mode component
>> only, so there is no sense in keeping the tap driver as dependency
>> (build and sign).
>>
>> Regards,
>> Alon.
>>
>> [1] https://www.opensc-project.org/build/
>> [2] https://www.opensc-project.org/build/browser
>> [3] http://sourceforge.net/projects/osslsigncode/
>>
>> 2011/11/24 Samuli Seppänen 
>>>
>>> Hi,
>>>
>>> We're having an IRC meeting today, starting at 18:00 UTC on
>>> #openvpn-de...@irc.freenode.net. Current topic list 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.
>>>
>>> NOTE: It's required to use a registered Freenode IRC nickname to join
>>> #openvpn-devel - look here for details:
>>>
>>> 
>>>
>>> --
>>> Samuli Seppänen
>>> Community Manager
>>> OpenVPN Technologies, Inc
>>>
>>> irc freenode net: mattock
>>>
>>> --
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>> ___
>>> Openvpn-devel mailing list
>>> Openvpn-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>
>

Re: [Openvpn-devel] Topics for today's meeting

[Jan Just Keijser]

Alon Bar-Lev wrote:
> I hate CMake, it is way too complex, these guys re-invented the wheel
> with no decent reuse of any methodology / language that existed
> before.
>   
I agree with Alon here :

+1 autoconf
-9 CMake

esp troubleshooting a non-working CMake setup is a nightmare.

JJK
> If we take SCons as another example, it took python and used it to do
> build... So if you are python developer most probably you know how to
> SCons.
> Also, look the huge backlog of bugs of CMake, it is amazing!
>
> Common to both CMake and SCons is the ability to work with Microsoft
> toolchain to produce binaries. This is a great advantage over the
> autotools. However, these tools are inferior when it comes to
> autotools (provided you know what you are doing) in *NIX, embedded and
> cross compile.
>
> To build using CMake or SCCons you need these tools on *TARGET*
> machine, these tools has LONG LIST of dependencies. To build using
> autotools you need POSIX utils (sh, sed, ls, rm, ...) and POSIX make
> and that's it!
>
> I don't mind if for Windows CMake/SCons will be maintain in addition,
> keep autotools usage for windows cross compile and *NIX build using
> autotools.
>
> Alon.
>
> On Thu, Nov 24, 2011 at 11:25 AM, Adriaan de Jong  wrote:
>   
>> Just to put in my 2cents on the build options: there is a tool that supports 
>> all of those environments (gmake, cygwin, mingw, nmake, visual studio, 
>> eclipse, ), and that's CMake. It's widely used, and has a pretty good 
>> track record. It can also support automated test environments and packaging.
>>
>> It has one major disadvantage: the current build system would need to be 
>> converted from an autoconf-based to a new CMake-based system, together with 
>> all of the knowledge contained within it. Further, there is less knowledge 
>> of CMake than autoconf within the OpenVPN community.
>>
>> Disclaimer: I'm not trying to start a holy war here, I know every system has 
>> its own advantages and drawbacks. I just want to get the option on the table 
>> :). I've had some positive experience with CMake, through PolarSSL and some 
>> projects at work. I'll try to make it to the meeting this evening for the 
>> discussion.
>>
>> Kind Regards,
>>
>> Adriaan
>>
>> 
>>> -Original Message-
>>> From: Samuli Seppänen [mailto:sam...@openvpn.net]
>>> Sent: donderdag 24 november 2011 9:48
>>> To: openvpn-devel@lists.sourceforge.net
>>> Subject: [Openvpn-devel] Topics for today's meeting
>>>
>>> Hi,
>>>
>>> We're having an IRC meeting today, starting at 18:00 UTC on #openvpn-
>>> de...@irc.freenode.net. Current topic list 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.
>>>
>>> NOTE: It's required to use a registered Freenode IRC nickname to join
>>> #openvpn-devel - look here for details:
>>>
>>>   

Re: [Openvpn-devel] Topics for today's meeting

[Alon Bar-Lev]

I hate CMake, it is way too complex, these guys re-invented the wheel
with no decent reuse of any methodology / language that existed
before.
If we take SCons as another example, it took python and used it to do
build... So if you are python developer most probably you know how to
SCons.
Also, look the huge backlog of bugs of CMake, it is amazing!

Common to both CMake and SCons is the ability to work with Microsoft
toolchain to produce binaries. This is a great advantage over the
autotools. However, these tools are inferior when it comes to
autotools (provided you know what you are doing) in *NIX, embedded and
cross compile.

To build using CMake or SCCons you need these tools on *TARGET*
machine, these tools has LONG LIST of dependencies. To build using
autotools you need POSIX utils (sh, sed, ls, rm, ...) and POSIX make
and that's it!

I don't mind if for Windows CMake/SCons will be maintain in addition,
keep autotools usage for windows cross compile and *NIX build using
autotools.

Alon.

On Thu, Nov 24, 2011 at 11:25 AM, Adriaan de Jong  wrote:
> Just to put in my 2cents on the build options: there is a tool that supports 
> all of those environments (gmake, cygwin, mingw, nmake, visual studio, 
> eclipse, ), and that's CMake. It's widely used, and has a pretty good 
> track record. It can also support automated test environments and packaging.
>
> It has one major disadvantage: the current build system would need to be 
> converted from an autoconf-based to a new CMake-based system, together with 
> all of the knowledge contained within it. Further, there is less knowledge of 
> CMake than autoconf within the OpenVPN community.
>
> Disclaimer: I'm not trying to start a holy war here, I know every system has 
> its own advantages and drawbacks. I just want to get the option on the table 
> :). I've had some positive experience with CMake, through PolarSSL and some 
> projects at work. I'll try to make it to the meeting this evening for the 
> discussion.
>
> Kind Regards,
>
> Adriaan
>
>> -Original Message-
>> From: Samuli Seppänen [mailto:sam...@openvpn.net]
>> Sent: donderdag 24 november 2011 9:48
>> To: openvpn-devel@lists.sourceforge.net
>> Subject: [Openvpn-devel] Topics for today's meeting
>>
>> Hi,
>>
>> We're having an IRC meeting today, starting at 18:00 UTC on #openvpn-
>> de...@irc.freenode.net. Current topic list 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.
>>
>> NOTE: It's required to use a registered Freenode IRC nickname to join
>> #openvpn-devel - look here for details:
>>
>> > nnel>
>>
>> --
>> Samuli Seppänen
>> Community Manager
>> OpenVPN Technologies, Inc
>>
>> irc freenode net: mattock
>>
>> ---
>> ---
>> All the data continuously generated in your IT infrastructure contains
>> a definitive record of customers, application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and
>> makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

Re: [Openvpn-devel] Topics for today's meeting

[Alon Bar-Lev]

Correction!
cygwin provides mingw-w64 now!!!
Also recent autoconf/automake/libtool.
So we can also cross compile using mingw.

2011/11/24 Alon Bar-Lev :
> Hello,
>
> I won't participate in sync meeting don't have the time.
> Anyway, for windows build.
> I already provide binaries for OpenVPN using mingw-w64 project, and it
> works fine!
> I use mingw-w64 for both win32 and win64 binaries, much better than
> old mingw project, as mingw-w64 is maintained!
> You can see my build system at [1][2].
> So mingw cross compile is supported. I would have re-written the
> openvpn autoconf script to clean it up and make it more standard, but
> current is enough to be usable.
>
> msys can be used on Windows to build not sure it worth the effort...
> mingw can be used with -mno-cygwin parameter, but from my experience
> the toolchain in cygwin are way too old to be usable.
>
> For the tap driver, I always note this... IT SHOULD BE SEPARATE MSI
> and SEPARATE PROJECT.
> There should be absolutely no dependency between openvpn release cycle
> and tap release cycle.
> It is just like wireshark and libpcap projects.
> OpenVPN installer can embed the tap msi and run it during installation.
> When tap installed, it should register its version in registry key, so
> openvpn may read it in order to connect (currently it is done
> hardcoded within openvpn).
>
> The TAP driver should be built and signed using Microsoft toolchain,
> there is no problem in that. There is almost a single developer for
> the tap driver..
> The usermode components may be signed on Linux using the
> osslsigncode[3], so actual signing is not an issue, if this is desired
> I can submit a patch for "make install" to sign, as I do in other
> projects.
>
> Most (99%) users are interested in building custom user mode component
> only, so there is no sense in keeping the tap driver as dependency
> (build and sign).
>
> Regards,
> Alon.
>
> [1] https://www.opensc-project.org/build/
> [2] https://www.opensc-project.org/build/browser
> [3] http://sourceforge.net/projects/osslsigncode/
>
> 2011/11/24 Samuli Seppänen 
>>
>> Hi,
>>
>> We're having an IRC meeting today, starting at 18:00 UTC on
>> #openvpn-de...@irc.freenode.net. Current topic list 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.
>>
>> NOTE: It's required to use a registered Freenode IRC nickname to join
>> #openvpn-devel - look here for details:
>>
>> 
>>
>> --
>> Samuli Seppänen
>> Community Manager
>> OpenVPN Technologies, Inc
>>
>> irc freenode net: mattock
>>
>> --
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

Re: [Openvpn-devel] Topics for today's meeting

[Adriaan de Jong]

Just to put in my 2cents on the build options: there is a tool that supports 
all of those environments (gmake, cygwin, mingw, nmake, visual studio, eclipse, 
), and that's CMake. It's widely used, and has a pretty good track record. 
It can also support automated test environments and packaging.

It has one major disadvantage: the current build system would need to be 
converted from an autoconf-based to a new CMake-based system, together with all 
of the knowledge contained within it. Further, there is less knowledge of CMake 
than autoconf within the OpenVPN community.

Disclaimer: I'm not trying to start a holy war here, I know every system has 
its own advantages and drawbacks. I just want to get the option on the table 
:). I've had some positive experience with CMake, through PolarSSL and some 
projects at work. I'll try to make it to the meeting this evening for the 
discussion.

Kind Regards,

Adriaan

> -Original Message-
> From: Samuli Seppänen [mailto:sam...@openvpn.net]
> Sent: donderdag 24 november 2011 9:48
> To: openvpn-devel@lists.sourceforge.net
> Subject: [Openvpn-devel] Topics for today's meeting
> 
> Hi,
> 
> We're having an IRC meeting today, starting at 18:00 UTC on #openvpn-
> de...@irc.freenode.net. Current topic list 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.
> 
> NOTE: It's required to use a registered Freenode IRC nickname to join
> #openvpn-devel - look here for details:
> 
>  nnel>
> 
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
> 
> irc freenode net: mattock
> 
> ---
> ---
> All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and
> makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Topics for today's meeting

[Alon Bar-Lev]

Hello,

I won't participate in sync meeting don't have the time.
Anyway, for windows build.
I already provide binaries for OpenVPN using mingw-w64 project, and it
works fine!
I use mingw-w64 for both win32 and win64 binaries, much better than
old mingw project, as mingw-w64 is maintained!
You can see my build system at [1][2].
So mingw cross compile is supported. I would have re-written the
openvpn autoconf script to clean it up and make it more standard, but
current is enough to be usable.

msys can be used on Windows to build not sure it worth the effort...
mingw can be used with -mno-cygwin parameter, but from my experience
the toolchain in cygwin are way too old to be usable.

For the tap driver, I always note this... IT SHOULD BE SEPARATE MSI
and SEPARATE PROJECT.
There should be absolutely no dependency between openvpn release cycle
and tap release cycle.
It is just like wireshark and libpcap projects.
OpenVPN installer can embed the tap msi and run it during installation.
When tap installed, it should register its version in registry key, so
openvpn may read it in order to connect (currently it is done
hardcoded within openvpn).

The TAP driver should be built and signed using Microsoft toolchain,
there is no problem in that. There is almost a single developer for
the tap driver..
The usermode components may be signed on Linux using the
osslsigncode[3], so actual signing is not an issue, if this is desired
I can submit a patch for "make install" to sign, as I do in other
projects.

Most (99%) users are interested in building custom user mode component
only, so there is no sense in keeping the tap driver as dependency
(build and sign).

Regards,
Alon.

[1] https://www.opensc-project.org/build/
[2] https://www.opensc-project.org/build/browser
[3] http://sourceforge.net/projects/osslsigncode/

2011/11/24 Samuli Seppänen 
>
> Hi,
>
> We're having an IRC meeting today, starting at 18:00 UTC on
> #openvpn-de...@irc.freenode.net. Current topic list 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.
>
> NOTE: It's required to use a registered Freenode IRC nickname to join
> #openvpn-devel - look here for details:
>
> 
>
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
> irc freenode net: mattock
>
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Topics for today's meeting

[Samuli Seppänen]

Hi,

We're having an IRC meeting today, starting at 18:00 UTC on
#openvpn-de...@irc.freenode.net. Current topic list 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.

NOTE: It's required to use a registered Freenode IRC nickname to join
#openvpn-devel - look here for details:



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

irc freenode net: mattock