[Openvpn-devel] Weekly Snapshots

[Eric Crist]

Beginning with this past week, I plan to sign the weekly snapshots and most a 
message to the list with the signature.  I believe it'll prove more difficult 
to doctor everyone's email than a single file on my FTP servers.  These tar 
balls are generated every Sunday at 00:00 CST if there have been new commits.  
There is also a brief change log that can be found in revision.log.  You may 
use ftp.secure-computing.net or ftp2.secure-computing.net in pub/openvpn.

Without further ado, the signature for week 49 of 2011:

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAABAgAGBQJO4nF3AAoJEHKWQhk5DQ0Oq90IAIr8VLaHIaACguVqy0vVx3nl
Z+5xiRS5ziH/RNmfmAR+zAQTCN6TC6dnns6BA0z/vzSeFW0ftarid/OC0/X3qF5d
TEpjN3QZz6N2LAS898J7zJCbnDq7CTpX7CkxnNk4NSXO5ej2iFFqGeGHDK8L85aV
xNFGZc3RFoaHKjFw6T7EPd6BPYoc8IniSAqIYDNvKxnBAYsCbjqvPnQkhTMrJO4f
aoKpdRfgajEb4joXmbxpOpl8zxtP7WEbeBBVKQXfZtKU0W+/nOwcMiFTngCcuD60
xi6HNlA7jDgv1fKpdW1EWQCZfBP8E7iBlIGLYQPY9qjDNQbp/Oj4YDbYoFmMrxA=
=op6Z
-END PGP SIGNATURE-


-
Eric F Crist
Secure Computing Networks





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Openvpn-devel] [PATCH v3] Move away from openvpn_basename() over to platform provided basename()

[Alon Bar-Lev]

On Fri, Dec 9, 2011 at 5:26 PM, David Sommerseth
 wrote:
>> These changes, just to take into account some system somewhere that
>> has a basename() implementation that modifies the argument string, are
>> ugly, and prone to memleak-errors.  Also, some other "basename(3)" man
>> pages talk about basename() returning a pointer to an internal static
>> storage which can be overwritten at the next call - so the code above
>> would then not work on such a system (as the next call to basename()
>> would modify the memory are where options->dev is pointing to).
>
> For the record, I did some valgrind checks on this change.  And for some
> odd reason, this doesn't leak.  Even though --dev-node is explicitly set.
>  But it might be that the gc_* magic functions somehow catches this
> allocation as well.
>
> Also note that init_options_dev() is only called once during the
> execution, and this allocation *only* happens if --dev-node is used.
>
> And the only reason I say this is to try to avoid posting a v4 patch ;-)
>
>> So I'd propose to keep openvpn_basename() - it's simple and short
>> enough, and has well-defined semantics that can be relied upon.
>
> The original openvpn_basename() is based upon the GNU basename() which is
> not modifying any arguments, so this is definitely cleaner.

In my opinion, in order to avoid confusion there can be two options:

1. Use library functions as much as possible, providing the minimum
common ground
in compatibility layer if missing. This ensure applying fixes and
functionality from
various upstreams.

2. Use own implementation everywhere, taking responsibility and
control over the implementation
and maintenance.

Mix is only confusing, and leads to even more errors.

This also applied to related functions such as dirname/basename in
this case, choosing own
implementation of basename yield confusing as you do not expect that
dirname taken from
different implementation.

Regards,
Alon.

Re: [Openvpn-devel] [PATCH v3] Move away from openvpn_basename() over to platform provided basename()

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

(resent - go get it into the mailing list too)

On 09/12/11 09:02, Gert Doering wrote:
> Hi,
> 
> On Thu, Dec 08, 2011 at 04:24:20PM +0100, David Sommerseth wrote:
>> This kicks out the openvpn_basename() function from misc.[ch] and 
>> puts glibc equivalents into compat.[ch].  This is to provide the 
>> same functionality on platforms not having a native basename() 
>> function available.
>> 
>> In addition this patch adds dirname() which commit 0f2bc0dd92f43c91e
>> depends.  Without dirname(), openvpn won't build in Visual Studio.
>> 
>> v2: Move all functions from compat.h to compat.c v3: Use glibc 
>> versions of basename() and dirname() instead
> 
> ACK for the dirname() part.
> 
> I'm not particularily happy with the basename() changes, though.
> 
>> --- a/init.c +++ b/init.c @@ -862,8 +862,10 @@ init_verb_mute 
>> (struct context *c, unsigned int flags) void init_options_dev 
>> (struct options *options) { -  if (!options->dev) -options->dev 
>> = openvpn_basename (options->dev_node); +  if (!options->dev && 
>> options->dev_node) { +char *dev_node = 
>> strdup(options->dev_node); /* POSIX basename() implementaions may 
>> modify its arguments */ +options->dev = basename (dev_node); + }
>> }
> 
> These changes, just to take into account some system somewhere that 
> has a basename() implementation that modifies the argument string, are
> ugly, and prone to memleak-errors.  Also, some other "basename(3)" man
> pages talk about basename() returning a pointer to an internal static
> storage which can be overwritten at the next call - so the code above
> would then not work on such a system (as the next call to basename()
> would modify the memory are where options->dev is pointing to).

For the record, I did some valgrind checks on this change.  And for some
odd reason, this doesn't leak.  Even though --dev-node is explicitly set.
 But it might be that the gc_* magic functions somehow catches this
allocation as well.

Also note that init_options_dev() is only called once during the
execution, and this allocation *only* happens if --dev-node is used.

And the only reason I say this is to try to avoid posting a v4 patch ;-)

> So I'd propose to keep openvpn_basename() - it's simple and short 
> enough, and has well-defined semantics that can be relied upon.

The original openvpn_basename() is based upon the GNU basename() which is
not modifying any arguments, so this is definitely cleaner.

> OTOH, David's compat.c basename() is nicer than what we currently
> have - so let's use that implementation, but let's call it 
> openvpn_basename().

If there's a vote for a v4 version of this patch, I would then move this
one out of compat.c and back to misc.c ... and add the code which tackles
both / and \ in the same code.

*BUT* this will cause a nasty feature breakage, with tackling both / and
\.  As this will then work everywhere openvpn_basename() is used.  But
wherever dirname() is used in the code, it will be platform defined /
*or* \ ... or in case of lack of dirname() it will use both (Windows).

Which again, in my head, speaks for openvpn_dirname() as well ...

However, Windows is the platform which first of all needs to tackle both
/ and \, as it is possible to use both variants, afaik.


David S.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7iKJsACgkQDC186MBRfrq0VQCcC8P5Um4RkZbXwGH4ENMbJugs
MIkAn2ta/cC7ufmiSEMO1JOYBW1L0Jp0
=C+WB
-END PGP SIGNATURE-

[Openvpn-devel] OpenVPN 2.2.2 preview installer for Windows with pkcs11 support now available

[Samuli Seppänen]

Hi,

As some of you may have noticed, Windows versions of OpenVPN 2.2* have
so far lacked pkcs11 support. This is hopefully fixed now. If you want
help get 2.2.2 out a.s.a.p. and use pkcs11, please test the installer
you can find from here:



I've only verified that "openvpn --help" finds pkcs11-related options,
nothing more. The installer also contains a new versions of
pkcs11-helper (1.09) and OpenSSL (1.0.0e).

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

irc freenode net: mattock

[Openvpn-devel] Summary of the IRC meeting (8th Dec 2011)

[Samuli Seppänen]

Hi,

Here's the summary of the previous IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-devel on irc.freenode.net
List-Post: openvpn-devel@lists.sourceforge.net
Date: Thursday 8th Dec 2011
Time: 18:00 UTC

Planned meeting topics for this meeting were on this page:



Next meeting will be announced in advance, but will probably be on the same
weekday and at the same time. Your local meeting time is easy to check
from services such as



or with

$ date -u


SUMMARY

cron2, dazo, ecrist, krzie and mattock participated in this meeting.

--

Discussed the OpenVPN 2.2.2 release. Decided to have all blockers taken
care of by next Thursday:


1) Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0



Although this bug should be gone now, verification is needed. Mattock
asked all bug report commenters to test a fixed OpenVPN version. One of
them responded already, but hasn't yet tested the new version.


2) No client-to-client in server config, but also can ping other client
which logined vpn



Agreed that this is a configuration mistake.


3) IPv6 errors on server side



Dazo will provide a quick fix for this bug (write a sensible, one-time
warning message).


4) openvpn-2.2.1-install.exe contains unsigned openvpn-gui-1.0.3.exe



Mattock will fix this.


5) pkcs11 support is missing in openvpn 2.2.0 for windows



Mattock will fix this.


6) "Password save support missing in OpenVPN 2.2.1 Debian/Ubuntu packages"



Mattock will fix this issue.

--

Discussed the OpenVPN 2.3 alpha release. Decided to have all blockers
taken care of by late January. The following should be ready by then:

1) New connectivity test server

- provided by ecrist, thanks!
- configured by mattock


2) Connectivity test integration in buildslaves

- mattock: Linux buildslaves
- cron2: *BSD buildslaves
- ecrist: MacOS X buildslave


3) Fedora/CentOS packages missing



CentOS 6 RPM packages are ready, so adding Fedora packages is trivial.
Mattock will have those (along with yum repos) ready by 2.3 alpha.

Noted that while stable OpenVPN releases usually end up in rpmforge and
EPEL repositories quite quickly, various snapshot and alpha/beta
versions will still prove useful.


4) Various Visual Studio build fixes





David will take care of these.


5) Unicode fixes




Will try to include these in 2.3 alpha, but if necessary, postpone to a
later release.


6) WinXP: route setup broken after standby



Agreed that we should not postpone the 2.3 alpha release because of this.


7) openvpnserv.exe does not exit even if there are no openvpn.exe processes



For this a volunteer is needed. James did not volunteer due to lack of time.


8) push-reset should not reset topology and route-gateway from global config



This look like material for the "great configuration option parser
rewrite project, which needs to be done really carefully. Decided to
postpone fixing this until after 2.3.

--

Discussed the VLAN tagging patchset that surfaced again recently:



Agreed that postponing this to a post 2.3 release is acceptable.

---

Full chatlog as an attachment

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

irc freenode net: mattock

mattock 20:03:57
krzie: lo, excellent catch 
who's here? 20:04:06
 
krzie 20:04:36
o/  
cron2 not 20:04 

mattock 20:05:34
dazo?
while waiting, I'll add some tickets for myself to trac 20:06:01
 
dazo 20:06:15
yeah?   

mattock 20:09:10
meeting?
18:09 UTC 20:09:21
https://community.openvpn.net/openvpn/wiki/Topics-2011-12-08 20:09:34
 
vpnHelper 20:09:35
Title: Topics-2011-12-08 – OpenVPN Community (at community.openvpn.net)   

mattock 20:09:57
as suggested by cron2, a quick review of 2.2.2 / 2.3 alpha release status   

cron2 20:09:59
but mattock said he wouldn't be here... 

mattock 20:10:28
I'm his evil twin brother
you can trust me 20:10:33
 
cron2 20:12:32
ok: 2.2.2
what's missing? 20:12:47
 
mattock 20:12:53
there was this one bug in the TAP-driver

cron2 20:13:13
that one has been fixed 
dazo pokes at the open bugs 20:13   

Re: [Openvpn-devel] [PATCH v3] Move away from openvpn_basename() over to platform provided basename()

[Gert Doering]

Hi,

On Thu, Dec 08, 2011 at 04:24:20PM +0100, David Sommerseth wrote:
> This kicks out the openvpn_basename() function from misc.[ch] and puts
> glibc equivalents into compat.[ch].  This is to provide the same
> functionality on platforms not having a native basename() function
> available.
> 
> In addition this patch adds dirname() which commit 0f2bc0dd92f43c91e
> depends.  Without dirname(), openvpn won't build in Visual Studio.
> 
> v2: Move all functions from compat.h to compat.c
> v3: Use glibc versions of basename() and dirname() instead

ACK for the dirname() part.

I'm not particularily happy with the basename() changes, though.

> --- a/init.c
> +++ b/init.c
> @@ -862,8 +862,10 @@ init_verb_mute (struct context *c, unsigned int flags)
>  void
>  init_options_dev (struct options *options)
>  {
> -  if (!options->dev)
> -options->dev = openvpn_basename (options->dev_node);
> +  if (!options->dev && options->dev_node) {
> +char *dev_node = strdup(options->dev_node); /* POSIX basename() 
> implementaions may modify its arguments */
> +options->dev = basename (dev_node);
> +  }
>  }

These changes, just to take into account some system somewhere that
has a basename() implementation that modifies the argument string, are
ugly, and prone to memleak-errors.  Also, some other "basename(3)" man
pages talk about basename() returning a pointer to an internal static
storage which can be overwritten at the next call - so the code above 
would then not work on such a system (as the next call to basename() 
would modify the memory are where options->dev is pointing to).


So I'd propose to keep openvpn_basename() - it's simple and short enough,
and has well-defined semantics that can be relied upon.


OTOH, David's compat.c basename() is nicer than what we currently have -
so let's use that implementation, but let's call it openvpn_basename().

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


pgpnOp6yTD_pn.pgp
Description: PGP signature