Re: [Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

2009-12-09 Thread David Sommerseth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/12/09 11:54, Samuli Seppänen wrote:
> 
>> On Mon, Dec 07, 2009 at 12:25:09PM +0200, Samuli Seppänen wrote:
>>   
>>> Hello everybody,
>>>
>>> I'm the newly appointed community manager for OpenVPN Technologies. I
>>> will be acting as a liaison between OpenVPN community and OpenVPN
>>> Technologies. I will help us (the company) make our development more
>>> community-oriented, e.g. by providing the tools and making development
>>> 
>> [snip]
>>
>> Hi Samuli,
>>
>> Welcome! I hope the communication with the community will improve with
>> your help. In this regard, I'd like to know if it's in your duties to
>> deal with bug reports/feature requests, since there's a bunch [1] of
>> them reported in the Debian Bug Tracking System.
>>
>> Please don't hesitate to contact me if you need my help at any time.
>>
>> Thanks,
>>
>> Alberto
>>
>> [1] 
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags:upstream;dist=unstable;package=openvpn
>>
>>   
> Hi Gonzales,
> 
> We're definitely committed to making OpenVPN as close to a true
> community project as possible. This will require rethinking how OpenVPN
> development is done. In theory it's easy: just delegate responsibility
> to community members. The problem is how to keep the work organized so
> that the new development process actually produces better (and faster)
> results. This is something I've already discussed with some community
> members. One option mentioned was the Linux kernel model. In our case,
> James would be Linus who (mostly) reviews other people's patches and
> applies them. 

I strongly encourages such a model.  This might be not needed
information what I'm providing here now, but I'll add it for those who
are don't know or just are interested in one approach of how such a
community can work.  This is purely my own experiences with working with
such communities.

I believe James have received several patches in the past from people on
the mailing list - or directly.  At least I hope he keeps an eye on the
mailing list and might have an idea who might be potential candidates to
help out in his "inner circle".  Anyhow, it is important that this
circle includes people which he can trust 100%.  Each of these persons
(maybe they will concentrate on different parts of the OpenVPN code, but
this they need to arrange between themselves) will then pay attention to
patches which hits their segment/interest field and they can validate
these patches.  It don't need to be many persons, it can be one or it
can be fifteen, the amount is not that important, especially not right
now.  The important part is that there are someone who reviews and keeps
an open dialogue with the community and also have a good connection with
James.  They will either include patches into their own source trees, or
kick them back to be reworked or cancelled completely.

Patches which are accepted will then be sent to James for a final review
and inclusion.  If James don't like it, it must be discussed on the
mailing list so that everyone can see and understand why it was rejected
and how to make it more acceptable for inclusion.  If James can take the
time to bring this discussion on the mailing list directly himself in
these cases, that would bring the needed transparency.  Further, it
should hopefully not happen too often, as James' "inner circle" should
already have made sure it is suitable for inclusion.

These "inner circle" people do not need to be "community members".  I
don't know how big the OpenVPN Technologies Inc. company is, but it can
even be people from here.  But it is important that 1) James trust these
persons ultimately and will be willing to grant them more privileges, 2)
that these people are active and visible in the community.  Even patches
these people write themselves should be posted to the openvpn-devel list
(or other another more suitable one).  That way, more eyes can pay
attention and raise awareness if something seems to be wrong or needs to
be discussed.

This part is, IMHO, the most important part to get implemented first.
The rest will basically come as a result of this.

> I think we'd also need to build teams for various
> purposes, e.g. for QA, packaging, different GUI's... this would enable
> easy participation in OpenVPN development, whether you're a coder or
> not. This is something Ubuntu has done pretty well. 

Agreed, but this will need to come a litter bit later on.  IMHO, get the
development cycle in shape then QA and packaging/release engineering
must come immediately afterwords.  QA can most probably be done in
cooperation with the bigger Linux distributors as well.  The Fedora
community is working hard on a big testing framework called Beaker,
which is aimed at automatic testing of software.  (I even think Beaker
might support Windows testing in the future as well, but I have not
checked it out)  Other distroes might have similar systems as well.  The
important thing is to 

[Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

2009-12-09 Thread Samuli Seppänen

> On Mon, Dec 07, 2009 at 12:25:09PM +0200, Samuli Seppänen wrote:
>   
>> Hello everybody,
>>
>> I'm the newly appointed community manager for OpenVPN Technologies. I
>> will be acting as a liaison between OpenVPN community and OpenVPN
>> Technologies. I will help us (the company) make our development more
>> community-oriented, e.g. by providing the tools and making development
>> 
> [snip]
>
> Hi Samuli,
>
> Welcome! I hope the communication with the community will improve with
> your help. In this regard, I'd like to know if it's in your duties to
> deal with bug reports/feature requests, since there's a bunch [1] of
> them reported in the Debian Bug Tracking System.
>
> Please don't hesitate to contact me if you need my help at any time.
>
> Thanks,
>
> Alberto
>
> [1] 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags:upstream;dist=unstable;package=openvpn
>
>   
Hi Gonzales,

We're definitely committed to making OpenVPN as close to a true
community project as possible. This will require rethinking how OpenVPN
development is done. In theory it's easy: just delegate responsibility
to community members. The problem is how to keep the work organized so
that the new development process actually produces better (and faster)
results. This is something I've already discussed with some community
members. One option mentioned was the Linux kernel model. In our case,
James would be Linus who (mostly) reviews other people's patches and
applies them. I think we'd also need to build teams for various
purposes, e.g. for QA, packaging, different GUI's... this would enable
easy participation in OpenVPN development, whether you're a coder or
not. This is something Ubuntu has done pretty well. Currently we're
lacking basic community services (e.g. forums, trackers, wiki,
[sub]project hosting), but we're working on that. However I think the
basic development model should be agreed upon before building any services.

Anyways, I'm very interested in any ideas on how to organize the project
in a more community-oriented fashion. So please let me know of any ideas
/ insights you might have.

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






[Openvpn-devel] [PATCH] Hardened down-root.so plug-in with more context pointer checks

2009-12-09 Thread David Sommerseth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Make sure that the context is pointing somewhere before continuing.

Signed-off-by: David Sommerseth 
- ---
 plugin/down-root/down-root.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/plugin/down-root/down-root.c b/plugin/down-root/down-root.c
index 77497ad..000ac40 100644
- --- a/plugin/down-root/down-root.c
+++ b/plugin/down-root/down-root.c
@@ -274,6 +274,8 @@ openvpn_plugin_open_v1 (unsigned int *type_mask,
const char *argv[], const char
* Allocate our context
*/
   context = (struct down_root_context *) calloc (1, sizeof (struct
down_root_context));
+  if (!context)
+goto exit;
   context->foreground_fd = -1;

   /*
@@ -317,6 +319,9 @@ openvpn_plugin_func_v1 (openvpn_plugin_handle_t
handle, const int type, const ch
 {
   struct down_root_context *context = (struct down_root_context *) handle;

+  if (!context)
+return OPENVPN_PLUGIN_FUNC_ERROR;
+
   if (type == OPENVPN_PLUGIN_UP && context->foreground_fd == -1) /*
fork off a process to hold onto root */
 {
   pid_t pid;
@@ -409,6 +414,9 @@ openvpn_plugin_close_v1 (openvpn_plugin_handle_t handle)
 {
   struct down_root_context *context = (struct down_root_context *) handle;

+  if (!context)
+return;
+
   if (DEBUG (context->verb))
 fprintf (stderr, "DOWN-ROOT: close\n");

- -- 
1.6.2.5

(patch attached for convenience)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAksfdq4ACgkQDC186MBRfro7jgCgm3WM29OaAjIN1rnLbiFfEUm6
2pYAn3FVWu9++5Cl2lsT9FFJzvmop1T4
=Ywbn
-END PGP SIGNATURE-
>From c67bb0fb0afb3045b2b07873583086d6dfbad8e9 Mon Sep 17 00:00:00 2001
From: David Sommerseth 
List-Post: openvpn-devel@lists.sourceforge.net
Date: Wed, 9 Dec 2009 10:44:31 +0100
Subject: [PATCH] Hardened down-root.so plug-in with more context pointer checks

Make sure that the context is pointing somewhere before continuing.

Signed-off-by: David Sommerseth 
---
 plugin/down-root/down-root.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/plugin/down-root/down-root.c b/plugin/down-root/down-root.c
index 77497ad..000ac40 100644
--- a/plugin/down-root/down-root.c
+++ b/plugin/down-root/down-root.c
@@ -274,6 +274,8 @@ openvpn_plugin_open_v1 (unsigned int *type_mask, const char 
*argv[], const char
* Allocate our context
*/
   context = (struct down_root_context *) calloc (1, sizeof (struct 
down_root_context));
+  if (!context)
+goto exit;
   context->foreground_fd = -1;

   /*
@@ -317,6 +319,9 @@ openvpn_plugin_func_v1 (openvpn_plugin_handle_t handle, 
const int type, const ch
 {
   struct down_root_context *context = (struct down_root_context *) handle;

+  if (!context)
+return OPENVPN_PLUGIN_FUNC_ERROR;
+
   if (type == OPENVPN_PLUGIN_UP && context->foreground_fd == -1) /* fork off a 
process to hold onto root */
 {
   pid_t pid;
@@ -409,6 +414,9 @@ openvpn_plugin_close_v1 (openvpn_plugin_handle_t handle)
 {
   struct down_root_context *context = (struct down_root_context *) handle;

+  if (!context)
+return;
+
   if (DEBUG (context->verb))
 fprintf (stderr, "DOWN-ROOT: close\n");

-- 
1.6.2.5



0002-Hardened-down-root.so-plug-in-with-more-context-poin.patch.sig
Description: PGP signature


[Openvpn-devel] [PATCH] openvpn-down-root.so causes a segfault on premature exits

2009-12-09 Thread David Sommerseth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


If openvpn is interrupted before openvpn_plugin_open_v1() is called,
there is no context allocated which openvpn_plugin_abort_v1() can use.

Signed-off-by: David Sommerseth 

- ---
 plugin/down-root/down-root.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/plugin/down-root/down-root.c b/plugin/down-root/down-root.c
index 5e0c002..77497ad 100644
- --- a/plugin/down-root/down-root.c
+++ b/plugin/down-root/down-root.c
@@ -434,7 +434,7 @@ openvpn_plugin_abort_v1 (openvpn_plugin_handle_t handle)
 {
   struct down_root_context *context = (struct down_root_context *) handle;

- -  if (context->foreground_fd >= 0)
+  if (context && context->foreground_fd >= 0)
 {
   /* tell background process to exit */
   send_control (context->foreground_fd, COMMAND_EXIT);
- -- 
1.6.2.5

(patch attached in addition for convenience)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAksfbOUACgkQDC186MBRfrqSgwCeOZPg+70ryTCCyoW8D9QtLmeF
pwwAn2pWo9529hvBzlMgj8izabtG9Ioc
=o0Ym
-END PGP SIGNATURE-
>From e7e12e33025e7b83a8a97121433b46045144ded9 Mon Sep 17 00:00:00 2001
From: David Sommerseth 
List-Post: openvpn-devel@lists.sourceforge.net
Date: Wed, 9 Dec 2009 10:18:55 +0100
Subject: [PATCH] openvpn-down-root.so causes a segfault on premature exits

If openvpn is interrupted before openvpn_plugin_open_v1() is called,
there is no context allocated which openvpn_plugin_abort_v1() can use.

Signed-off-by: David Sommerseth 

---
 plugin/down-root/down-root.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/plugin/down-root/down-root.c b/plugin/down-root/down-root.c
index 5e0c002..77497ad 100644
--- a/plugin/down-root/down-root.c
+++ b/plugin/down-root/down-root.c
@@ -434,7 +434,7 @@ openvpn_plugin_abort_v1 (openvpn_plugin_handle_t handle)
 {
   struct down_root_context *context = (struct down_root_context *) handle;

-  if (context->foreground_fd >= 0)
+  if (context && context->foreground_fd >= 0)
 {
   /* tell background process to exit */
   send_control (context->foreground_fd, COMMAND_EXIT);
-- 
1.6.2.5



0001-openvpn-down-root.so-causes-a-segfault-on-premature.patch.sig
Description: PGP signature


Re: [Openvpn-devel] [Openvpn-users] Introducing OpenVPN Community Manager

2009-12-09 Thread Samuli Seppänen
Nick Owen ha scritto:
> 2009/12/7 Samuli Seppänen :
>   
>> Hello everybody,
>>
>> I'm the newly appointed community manager for OpenVPN Technologies. I
>> will be acting as a liaison between OpenVPN community and OpenVPN
>> Technologies. I will help us (the company) make our development more
>> community-oriented, e.g. by providing the tools and making development
>> more transparent, so that both the community and the company benefit. To
>> accomplish these goals I need to work with you. I'll keep my own work as
>> transparent as possible so that you can constantly provide feedback
>> (positive or negative). Also, if you have any suggestions let me know -
>> preferably using the OpenVPN mailinglists. You can also talk to me
>> ("mattock") in the OpenVPN IRC channel during daytime (in EET/EEST
>> timezone).
>>
>> Now onto more concrete topics... I'm currently looking into community
>> projects around OpenVPN. I've so far found 14 different OpenVPN GUI
>> projects and two forum/wiki projects. I've listed them here:
>>
>>  http://users.utu.fi/sjsepp/openvpn_community_projects.html
>>
>> Do you know of other OpenVPN-related projects?
>> 
>
> Samuli:
>
> I see you have WiKID Systems listed.  Thanks!
>
> Here's a link for a WiKID/OpenVPN  tutorial:
> http://www.wikidsystems.net/support/wikid-support-center/how-to/using-wikid-strong-authentication-with-openvpn/
>
> We also have a how-to for ssl-explorer back from before the
> Adito/OpenVPN-ALS fork.
> http://www.wikidsystems.net/support/wikid-support-center/how-to/how-to-secure-an-ssl-vpn-with-one-time-passcodes-and-mutual-authentication/.
> I haven't had time to update that, though it is on the to-do.  This
> setup takes advantage of WiKID's mutual https authentication to
> validate the SSL cert for the user, providing protection against
> network-based MITM attacks.
>
> In the long run, I'd be interested in a direct WiKID/OpenVPN-ALS
> plugin and to perhaps a combined WiKID token/openvpn client.
>
> Great work!
>
> Nick
>   
Hi Nick,

Just drop a mail to openvpn-als-devel if you want to start developing an
OpenVPN ALS WikID plugin:

https://lists.sourceforge.net/mailman/listinfo/openvpn-als-devel

You can also visit our IRC channel (#adito) at freenode.net. As ALS has
RADIUS support (like SSL-E), binding WikiD and ALS should be no problem.

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