Re: [Openvpn-devel] [Openvpn-users] [PATCH] Add support for specifying the syslog facility, as requested in trac #188.

[Gert Doering]

Hi,

On Fri, May 02, 2014 at 05:59:26PM +0200, Gert Doering wrote:
> > - Why not re-use facilitynames[] from sys/syslog.h, instead of adding
> >   something which is basically a duplicate of exactly that lookup table?
> Oh, wow.  I didn't know that this exists - learned something new today.

JFTR, this does *not* exist on Solaris (which we support) or AIX (which
we do not support yet, but I'm toying with it since it recently grew
TAP support...).

It does exist on Linux, FreeBSD, NetBSD, MacOS X, OpenBSD.

MinGW/Windows does not seem to have a syslog.h at all

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


pgpXnZgPckq59.pgp
Description: PGP signature

Re: [Openvpn-devel] [Openvpn-users] [PATCH] Add support for specifying the syslog facility, as requested in trac #188.

[Jonathan K. Bullard]

On Fri, May 2, 2014 at 11:20 AM, David Sommerseth <
openvpn.l...@topphemmelig.net> wrote:

> The core principle in OpenVPN's option
>  parsing is that the last argument wins.  So if you have f.ex. --ping-exit
> 3
> times in a command line and two times in a config file, it's the last one
> which really sets the option.  --syslog-facility should be no different.
>
> IMO, distro init.d scripts should add the config file as the last argument
> when they kick off openvpn.  If they add stuff which overrides the config
> file, then it's a bug in the init.d script.
>

That might be good for distros, but Tunnelblick purposefully starts OpenVPN
with "--management" *after* "--config"; other GUIs may do this, too.
Tunnelblick does this to make sure that the management interface is used
only by Tunnelblick. (Tunnelblick separately warns the user if the
configuration file contains "--management" or other problematic options.)

For some options, it is the *first* argument that wins: "--log",
"--log-append", and I think "--daemon" (and possibly some other options
like "--syslog"). Tunnelblick puts --log and --daemon first to make sure it
controls logging. (Tunnelblick sends the log to a file, which it monitors,
instead of logging through the management interface, so Tunnelblick (the
GUI) does not need to be running when the OpenVPN instance is running --
for example, when nobody is logged in.)

Re: [Openvpn-devel] [Openvpn-users] [PATCH] Add support for specifying the syslog facility, as requested in trac #188.

[Gert Doering]

Hi,

On Fri, May 02, 2014 at 05:20:02PM +0200, David Sommerseth wrote:
> - Why not re-use facilitynames[] from sys/syslog.h, instead of adding
>   something which is basically a duplicate of exactly that lookup table?

Oh, wow.  I didn't know that this exists - learned something new today.

We might have to figure out how this is portably used - I see it exists
on Linux and FreeBSD, at least, and both have it inside #ifdef SYSLOG_NAMES,
so our code might have to do

#define SYSLOG_NAMES
#include 

or such.  Plus possibly an autoconf test to see whether it's there, and
if not, fall back to something in compat/ - that would make the change
to options.c much smaller.

> - Further, why the #ifdef's on LOG_FTP, LOG_SYSLOG, LOG_UUCP?

"Because not all systems have them", I'd say :-) - syslog facilities are
far from universal, alas.

[..]
> Using --syslog-facility is a bare minimum acceptable but not preferred. 
> Rather consider --daemon [progname] [facility]  and --syslog [progname] 
> [facility].  If facility is not set, default to whatever is the default now 
> (IIRC, it is syslog).

I think it would be good to loosen the restrictions that --syslog has
to be called before --daemon, and move that to "latest option wins"
(as usual).  Haven't checked the code to see how complicated that is.

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


pgpPk68MvBMgg.pgp
Description: PGP signature

Re: [Openvpn-devel] [Openvpn-users] [PATCH] Add support for specifying the syslog facility, as requested in trac #188.

[David Sommerseth]

On 02/05/14 09:23, Gert Doering wrote:

Hi,

(why is this being discussed on -users?  Taking it over to -devel)

On Thu, May 01, 2014 at 09:52:45PM -0400, Timothe Litt wrote:

e.g. the following are valid:
   --daemon
 Daemonize, use the default progname (from PACKAGE)
for syslog

   --daemon my-vpn-daemon
 Daemonize, use "my-vpn-daemon" for the syslog progname.

   --daemon [local1]
 Daemonize, use the default progname, use the local1
syslog facility (unless --syslog-facility already specified one)

   --daemon my[local1]-vpn-daemon  --daemon
[local1]my-vpn-daemon --daemon my-vpn-daemon[local1]
 Daemonize, use "my-vpn-daemon" for the syslog
progname.
  Use the local1 syslog facility
(unless --syslog-facility already specified one)


Uh.  Feature-NAK - especially the last one really makes me want to throw up.

Using [] as part of an option string is a bad idea, because it is commonly
used for optional arguments (as you saw in David's question), and intermixing
option argument "A" and "B" in the same string is not going to help anyone.


Agreed!


If we take this at all - and I have reservations, because the amount of
code it brings in is quite significant - it should not touch the --daemon
command line.  It brings it's own config statement (--syslog-facility),
so there really is no reason to mess up the syntax for --daemon.

Also, --syslog-facility should be more clean, like

  --sysloc-facility facility [progname]

with "progname" actually being *optional*, not "marked by using rectangular
brackets".


Agreed as well.  This is primarily what I'd expect this to do too.


[..]

As I explain above, this is to make it possible to specify a facility
name in cases where the system init script uses --daemon before the user
can put a --syslog-facility.  --syslog-facility must precede --daemon or
--syslog because the latter two immediately switch logging to syslog;
they are what consume the facility code when they call openlog().


Init scripts can be adjusted.   Obscure code inside OpenVPN stays forever
(guess why the developers have so little time?  right, maintaining stuff
that someone else considered "a clever hack" 5 years ago).


On distros which don't have package management, this is probably a fine thing. 
 But on most Linux distros with package management, init.d scripts will be 
replaced on package updates.  As we don't provide init.d script for all 
distros, it will not really be possible to change this.  Further, it's not 
that uncommon that software adds a facility option, so I find this core 
feature a good enhancement.


But!  I do not like the [] syntax.  The core principle in OpenVPN's option 
parsing is that the last argument wins.  So if you have f.ex. --ping-exit 3 
times in a command line and two times in a config file, it's the last one 
which really sets the option.  --syslog-facility should be no different.


IMO, distro init.d scripts should add the config file as the last argument 
when they kick off openvpn.  If they add stuff which overrides the config 
file, then it's a bug in the init.d script.


Anyway NAK to the v2 patch.  Because it really didn't give answers to many of 
my questions.


- We do not need SYSLOG_CAPABILITY, is there another #ifdef which restricts
  SYSLOG somehow?  If yes, use that, if not, don't do this.

- Why not re-use facilitynames[] from sys/syslog.h, instead of adding
  something which is basically a duplicate of exactly that lookup table?

- Further, why the #ifdef's on LOG_FTP, LOG_SYSLOG, LOG_UUCP?

- Don't fiddle around with malloc().  Use gc_arena and the string buffer
  functions defined in buffer.c/h


Please, make the next round a far more simpler version, reuse what is already 
implemented and well tested other places rather than re-inventing the wheel.


Using --syslog-facility is a bare minimum acceptable but not preferred. 
Rather consider --daemon [progname] [facility]  and --syslog [progname] 
[facility].  If facility is not set, default to whatever is the default now 
(IIRC, it is syslog).



--
kind regards,

David Sommerseth

Re: [Openvpn-devel] [Openvpn-users] [PATCH] Add support for specifying the syslog facility, as requested in trac #188.

[David Sommerseth]

On 02/05/14 09:23, Gert Doering wrote:

Hi,

(why is this being discussed on -users?  Taking it over to -devel)


That's my fault.  Well, it was the "Correct Identity" add-on in Thunderbird 
which suddenly began to pick the wrong identity (-users ML) which has a 
different reply-to setting.  Sorry about that!


--
kind regards,

David Sommerseth

[Openvpn-devel] OpenVPN 2.3.4 released

[Samuli Seppänen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The OpenVPN community project team is proud to release OpenVPN 2.3.4.
It can be downloaded from here:



The most important change in this release is that TLS version
negotiation is no longer used unless it's explicitly turned on in the
configuration files, thus reverting back to the 2.3.2 behaviour as
interoperability issues were encountered in 2.3.3. Other notable
changes include addition of SSL library version reporting, fixing of
SOCKSv5 authentication logic and making serial env exporting
consistent between OpenSSL and PolarSSL. This release also contains a
number of other bug fixes and small enhancements.

The Windows installer I001 has additional code to prevent problems
during install and uninstall if installer bitness is wrong or if the
OpenVPN-GUI or an OpenVPN process is running. The Windows installers
also bundle OpenSSL 1.0.1g, which means that they are immune to the
heartbleed vulnerability:




All Windows users of OpenVPN 2.3-rc2-I001 through OpenVPN 2.3.2-I003
should upgrade their installations immediately.

Experimental Windows installers with NDIS 6 -enabled tap-windows
drivers are also available for Windows Vista and above, here:



Note that it is possible, even if unlikely, that the NDIS 6 drivers
could crash, giving a BSOD. Long story short: please do not use them
on valuable production systems.

A full list of changes is available here:



The changelog is also attached to this email.

For generic help use these support channels:

- - Official documentation:

- - Wiki: 
- - Forums: 
- - User mailing list: 
- - User IRC channel: #openvpn at irc.freenode.net

Please report bugs and ask development questions here:

- - Bug tracker and Wiki: 
- - Developer mailing list: 
- - Developer IRC channel: #openvpn-devel at irc.freenode.net (requires
  Freenode registration)

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

irc freenode net: mattock



-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNjo4EACgkQwp2X7RmNIqNOuACeM190nx7c4RPcSQ+x/JS4c1W5
ozoAn0Ep1W3PxFWaalXEoMo0JL/KtS82
=8CX/
-END PGP SIGNATURE-
Arne Schwabe (1):
  Fix man page and OSCP script: tls_serial_{n} is decimal

Dmitrij Tejblum (1):
  Fix is_ipv6 in case of tap interface.

Gert Doering (8):
  IPv6 address/route delete fix for Win8
  Add SSL library version reporting.
  Minor t_client.sh cleanups
  Repair --multihome on FreeBSD for IPv4 sockets.
  Rewrite manpage section about --multihome
  More IPv6-related updates to the openvpn man page.
  Conditionalize calls to print_default_gateway on !ENABLE_SMALL
  Preparing for release v2.3.4 (ChangeLog, version.m4)

James Yonan (2):
  Use native strtoull() with MSVC 2013.
  When tls-version-min is unspecified, revert to original versioning 
approach.

Steffan Karger (4):
  Change signedness of hash in x509_get_sha1_hash(), fixes compiler warning.
  Fix OCSP_check.sh to also use decimal for stdout verification.
  Fix build system to accept non-system crypto library locations for 
plugins.
  Make serial env exporting consistent amongst OpenSSL and PolarSSL builds.

Yawning Angel (1):
  Fix SOCKSv5 method selection

kangsterizer (1):
  Fix typo in sample build script to use LDFLAGS



openvpn-2.3.4-changelog.sig
Description: PGP signature

Re: [Openvpn-devel] [Openvpn-users] [PATCH] Add support for specifying the syslog facility, as requested in trac #188.

[Gert Doering]

Hi,

On Fri, May 02, 2014 at 08:15:01AM -0400, Timothe Litt wrote:
> >(why is this being discussed on -users?  Taking it over to -devel)
> Er, I did post it to -devel, and I don't see any discussion of it on 
> -users...I just double-checked the archives, and it's all in -devel...

The mail I replied to went to -users, and only there...

> >  --syslog-facility should be more clean, like
> >
> >  --sysloc-facility facility [progname]
>
> --daemon and --syslog already control syslog's program name. Since we 
> would have to support the
> existing usages, your suggestion to add that to --syslog-facility would 
> add complexity, not simplify things.
> You really don't want that.

Then let's not do that.  Fine with me :-)

> >  intermixing
> >option argument "A" and "B" in the same string is not going to help anyone.
> Sorry that you don't like my accommodation for init scripts.  It helps 
> OpenVPN and its USERS.

"Helping init scripts" is actually something that only helps distribution
builders, and they are few, and usually listen quite well if we tell them 
what needs to be adjusted.

"Having unmaintainable code inside OpenVPN" is something that does not
help anyone - people will forget why it is the way it is, break it when
changing something else, and that will cause endless pain.  We've been
through that right now when rewriting socket.c to properly support
dual-stack systems, breaking *some* bits of SOCKS proxy support in the
process, breaking --inetd in the process, and so on - so we know all
about non-intuitive options and hard-to-maintain code.

[..]
> >the last one really makes me want to throw up.
> Yes, it's ugly.   And my stomach rumbles too.

So do not write such code, and do not expect us to merge it.

> If OpenVPN were engineered from scratch, --daemon would just daemonize, 
> --syslog would control the syslog program name and facility, and the two 
> could be used together.  And there wouldn't be silly ordering 
> constraints among the options.  But that's not the way the existing code 
> -- and customers' config and distros' init files -- work.

Then let's fix *that* problem (the ordering constraints), instead of adding 
more convolutions.  That would indeed help "OpenVPN and the users".

> This is the real world, and sometimes we have to live with ugly. Even if 
> it makes us a little queasy.

No :-) - it's open source world, and since everyone can see what we do,
we're not going to add more ugliness if we can avoid it.

Closed source works differently.

[..]
> So it has to be something that can be embedded anywhere in the string,  
> And that means delimiters on both ends.

"Anywhere in the string" is a hard "no".

[..]
> I didn't ignore it for 2 years, and I didn't let aesthetics get in the 
> way of the best solution that I could come up with.

Yeah,  I understand that the amount of free time we can give into OpenVPN
is annoying you.  It's annoying me as well that I have spend time in 
paid-for projects not related to OpenVPN to help feed my family, or that
David had to tune down his involvement into OpenVPN due to health reasons.

The amount of cleanup we've done in the last two years is quite enormous :-)
- even if it's not really visible outside of the git log.

[..]
> >Feature-NAK
> If you don't want the feature, why did you write in Trac #188:

I'm fine with the addition of a way to set the syslog-facility, but not 
the way it is presented.  Not intermixing stuff in other stuff in 
arguments.

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


pgpAj00UqMIFK.pgp
Description: PGP signature

Re: [Openvpn-devel] [Openvpn-users] [PATCH] Add support for specifying the syslog facility, as requested in trac #188.

[Timothe Litt]

(why is this being discussed on -users?  Taking it over to -devel)
Er, I did post it to -devel, and I don't see any discussion of it on 
-users...I just double-checked the archives, and it's all in -devel...



  --syslog-facility should be more clean, like

  --sysloc-facility facility [progname]
--daemon and --syslog already control syslog's program name. Since we 
would have to support the
existing usages, your suggestion to add that to --syslog-facility would 
add complexity, not simplify things.

You really don't want that.


  intermixing
option argument "A" and "B" in the same string is not going to help anyone.
Sorry that you don't like my accommodation for init scripts.  It helps 
OpenVPN and its USERS.



Init scripts can be adjusted.
The fact is that I'm not going to get all the distributions to change 
their init scripts, and neither are you.  It's a major effort to do that 
and get it coordinated across all the distributions.  No one  -- not me, 
not you, and not the distro maintainers -- has time for that.


Asking our users to do it piecemeal - and maintain it or lobby their 
distributions is not good engineering.  It's a problem that we can solve 
on this end.


Even if one could get distro cycles to change their init scripts - why 
would we waste them on something like this?  We'll

want them when we want something that can't be handled without their help...


the last one really makes me want to throw up.

Yes, it's ugly.   And my stomach rumbles too.

If OpenVPN were engineered from scratch, --daemon would just daemonize, 
--syslog would control the syslog program name and facility, and the two 
could be used together.  And there wouldn't be silly ordering 
constraints among the options.  But that's not the way the existing code 
-- and customers' config and distros' init files -- work.


This is the real world, and sometimes we have to live with ugly. Even if 
it makes us a little queasy.



Using [] as part of an option string is a bad idea, because it is commonly
used for optional arguments (as you saw in David's question), and


As for the choice of square brackets - the delimiter had to be something 
easy to parse that is uncommon in program and file names.


The init file usage does not make it easy.  Facility can not be a 
prefix, because the Debian usage I cite generates the --daemon argument
from the config file name -- adding a prefix.  It can't be a suffix 
because of the way systemd-based distros auto-generate multiple instances.


So it has to be something that can be embedded anywhere in the string,  
And that means delimiters on both ends.


I was aware that [ ] is used for 'optional' in syntax descriptions when 
I picked them.  But I provided examples to clarify the point.
And the other choices were worse, as they have other meanings to shells 
and filesystems.  At least [ ] is visually distinctive and

easy to remember.

It could be something else.  Do you have a better idea that doesn't add 
complexity?



It brings it's own config statement (--syslog-facility)
Actually, the first pass didn't - the facility was ONLY in the progname 
argument.  See the patch in Trac, which was the minimal

change required to solve the problems.

However, the additional code is minimal, and for cases where it is 
possible to avoid the ugly overloading of progname, it is a cleaner
way to specify facility.  I thought it worth the effort so as not to 
force ugliness on users when it isn't required.



someone else considered "a clever hack"


None of this was the result of random choices or "cleverness". I've been 
in the software business long enough to have dealt
with more of that than most.  Try adding a major feature to a 30-year 
old OS that's written in assembler...or to microcode.


I thought carefully about the issues, the requirement and how to meet it 
in a way that minimizes the internal and external impacts.


I'm busy too - but I took the time to understand the problem and do a 
proper job.  I checked multiple distributions, consulted
standards, localized the changes and did careful testing in the 
environments that I have.  And tried to give back to the community.


I could have just compiled with -DLOG_OPENVPN=LOG_LOCAL5 and gone on 
with my life... Or thrown an 'elegant' solution over

the wall and left customers to deal with the init file issues.

I didn't ignore it for 2 years, and I didn't let aesthetics get in the 
way of the best solution that I could come up with.



If we take this at all - and I have reservations, because the amount of
code it brings in is quite significant
The scope is hardly large.  If you look at the actual code - the size of 
the patch is dominated by documentation and the lookup table.
There are a couple of lines to parse the option, a subroutine to lookup 
the names, and local block of code in open to handle the syntax.


Although the init-script compatibility is ugly and adds a few lines of 
code, it meets the requirements with the least 

Re: [Openvpn-devel] [Openvpn-users] [PATCH] Add support for specifying the syslog facility, as requested in trac #188.

[Gert Doering]

Hi,

(why is this being discussed on -users?  Taking it over to -devel)

On Thu, May 01, 2014 at 09:52:45PM -0400, Timothe Litt wrote:
> e.g. the following are valid:
>   --daemon
> Daemonize, use the default progname (from PACKAGE) 
> for syslog
> 
>   --daemon my-vpn-daemon
> Daemonize, use "my-vpn-daemon" for the syslog progname.
> 
>   --daemon [local1]
> Daemonize, use the default progname, use the local1 
> syslog facility (unless --syslog-facility already specified one)
> 
>   --daemon my[local1]-vpn-daemon  --daemon 
> [local1]my-vpn-daemon --daemon my-vpn-daemon[local1]
> Daemonize, use "my-vpn-daemon" for the syslog 
> progname.
>  Use the local1 syslog facility 
> (unless --syslog-facility already specified one)

Uh.  Feature-NAK - especially the last one really makes me want to throw up.

Using [] as part of an option string is a bad idea, because it is commonly
used for optional arguments (as you saw in David's question), and intermixing
option argument "A" and "B" in the same string is not going to help anyone.

If we take this at all - and I have reservations, because the amount of
code it brings in is quite significant - it should not touch the --daemon
command line.  It brings it's own config statement (--syslog-facility),
so there really is no reason to mess up the syntax for --daemon.

Also, --syslog-facility should be more clean, like

 --sysloc-facility facility [progname]

with "progname" actually being *optional*, not "marked by using rectangular
brackets".


[..]
> As I explain above, this is to make it possible to specify a facility 
> name in cases where the system init script uses --daemon before the user 
> can put a --syslog-facility.  --syslog-facility must precede --daemon or 
> --syslog because the latter two immediately switch logging to syslog; 
> they are what consume the facility code when they call openlog().
 
Init scripts can be adjusted.   Obscure code inside OpenVPN stays forever
(guess why the developers have so little time?  right, maintaining stuff
that someone else considered "a clever hack" 5 years ago).

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


pgpR2GjqX4Ja9.pgp
Description: PGP signature

[Openvpn-devel] [PATCH] Add support for specifying the syslog facility, requested in, trac #188. (Rev 2)

[Timothe Litt]

Reflects review comments from David; doc changes, single patch, one name 
change,

some clarification in the commit message.  No functional changes.

Detailed response/rationale in previous email.

From 4af33b94ad4e2509fb9bc195eb50404c0d2b7581 Mon Sep 17 00:00:00 2001
From: Timothe Litt 
List-Post: openvpn-devel@lists.sourceforge.net
Date: Thu, 1 May 2014 20:57:45 -0400
Subject: [PATCH] Add support for specifying the syslog facility, 
requested in trac #188.


Revision 2, reflects review comments from David.

Users want this because it allows them to have syslog put all OpenVPN 
messages

in specific file(s) by using syslog.conf.

Adds --syslog-facility name option, which must precede --daemon and 
--syslog.


Adds ability to specify facility as [name] in --daemon and --syslog's 
progname argument,
which makes it possible to specify the syslog facility name without 
modifying certain

system init scripts.  --syslog-facility takes precedence.

For example, Debian automatically generates a --daemon vpn-{configname}
directive.  If you name the config foo[local1].conf, it's as though you 
were able to
specify --syslog-facility local1 --daemon vpn-foo --config 
foo[local1].conf.  Absent
this feature, this isn't possible without modifying the 
distribution-provided init script.


--syslog-facility list (or any other undefined name) will list the 
facilities that the

platform supports.

The old method of -DLOG_OPENVPN still provides the facility used by default.

Thus, syslog facility can be specified in one of three ways:
  --syslog-facility
  --daemon or --syslog's progname argument with embedded [facility]
  -DLOG_OPENVPN

For a given configuration:
   if --syslog-facility is present, its argument determines the facility.
   Otherwise:
   if --daemon or --syslog has a progname argument that contains a 
[facility] string,

   the [facility] will be used.
   Otherwise:
  The compile-time default LOG_OPENVPN, usually 'daemon', is used.

This is forward and backward compatible with existing scripts & initfiles.

Signed-off-by: Timothe Litt 
---
 doc/openvpn.8 |   17 +++
 src/openvpn/error.c   |  129 
+++--

 src/openvpn/error.h   |1 +
 src/openvpn/options.c |   19 
 4 files changed, 163 insertions(+), 3 deletions(-)

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 34894e5..e25a39c 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -2169,6 +2169,12 @@ When unspecified,
 .B progname
 defaults to "openvpn".

+If --syslog-facility has not been specified and the name
+includes [facility], the specified syslog facility name will be used with
+the system logger.  This method of specifying the facility name may be
+useful when initialization scripts generate --daemon progname from
+the config file name.  This avoids the need to edit the script.
+
 When OpenVPN is run with the
 .B \-\-daemon
 option, it will try to delay daemonization until the majority of 
initialization

@@ -2188,6 +2194,17 @@ directive above for description of
 .B progname
 parameter.
 .TP
+.B \-\-syslog-faciity name
+When logging to syslog, use name (e.g. local1 or daemon) for the facility.
+If name is absent or not supported, a platform-dependent list of valid
+facility names is provided.
+
+Must be specified before --daemon and --syslog.
+If this is not convenient, the facility name may be specified as [name] in
+the name parameter of either directive.  See --daemon.
+
+If this option is not specified, the default facility is usually 'daemon'.
+.TP
 .B \-\-errors-to-stderr
 Output errors to stderr instead of stdout unless log output is 
redirected by one of the

 .B \-\-log
diff --git a/src/openvpn/error.c b/src/openvpn/error.c
index fd9f19d..53048bf 100644
--- a/src/openvpn/error.c
+++ b/src/openvpn/error.c
@@ -89,9 +89,10 @@ static bool machine_readable_output;   /* GLOBAL */
 /* Should timestamps be included on messages to stdout/stderr? */
 static bool suppress_timestamps; /* GLOBAL */

-/* The program name passed to syslog */
+/* The program name and facility passed to syslog */
 #if SYSLOG_CAPABILITY
 static char *pgmname_syslog;  /* GLOBAL */
+static int facility_syslog = -1; /* Unspec (RFC5424 - can not be 
negative) */

 #endif

 /* If non-null, messages should be written here (used for debugging 
only) */

@@ -439,6 +440,93 @@ out_of_memory (void)
   exit (1);
 }

+#if SYSLOG_CAPABILITY
+static int lookup_syslog_facility_code (const char *name, int default_code)
+{
+  static struct {
+int code;
+const char *const name;
+  } facnames[] = {
+{ LOG_AUTH, "auth" },
+#ifdef LOG_AUTHPRIV  /* Prefered (private), but non-POSIX */
+{ LOG_AUTHPRIV, "authpriv" },
+#else
+{ LOG_AUTH, "authpriv" }, /* Map to non-secure code */
+#endif
+{ LOG_CRON, "cron" },
+{ LOG_DAEMON, "daemon" },
+#ifdef LOG_FTP
+{ LOG_FTP, "ftp" },
+#endif
+{ LOG_LPR, "lpr" },
+{ LOG_MAIL, "mail" },
+{ LOG_NEWS, "news" },
+#ifdef 

Re: [Openvpn-devel] IRC & Community...

[Eric Crist]

Sorry about the logs, I'll update the wiki.  My cronjob was putting the files 
in the wrong location.  It's better, so I'm going to leave them where they are 
now.

#openvpn: http://secure-computing.net/logs/openvpn.log
#openvpn-devel: http://secure-computing.net/logs/openvpn-devel.log

-
Eric F Crist



On May 1, 2014, at 17:37:04, David Sommerseth  
wrote:

> On 01/05/14 21:15, Gert Doering wrote:
>> Hi,
>> 
>> On Thu, May 01, 2014 at 08:06:46PM +0300, Samuli Seppänen wrote:
>>> A few notes about where we get our patches from... in the documentation
>>> we do say that "post the patch to openvpn-devel list". That was a
>>> decision that was reached some years ago. However, we, in practice, do
>>> accept patches from Trac, GitHub and IRC. We should probably change the
>>> documentation to reflect this.
>> 
>> Actually, openvpn-devel *is* the way, with trac being second (due to
>> the way we reference every commit to a mail on openvpn-devel, trac
>> patches basically need someone re-sending them to the list).
>> 
>> Github and IRC are *not* a welcome input for patches, because it doesn't
>> match the agreed-upon workflow ("ack or nack on the list, reference that
>> message in the commit"), and doesn't have the benefit of trac to be
>> tied to a ticket that can be set to a given milestone, etc.
>> 
>> IRC is very welcome to bounce around ideas ("should we fix this?  if
>> yes, in which way?") but it needs to result in a patch being sent to
>> openvpn-devel.  Actually, this is often the reason why some patches get
>> ACKed much quicker than others - they have been discussed, the reason
>> for the change is well-understood, and for complicated stuff, the details
>> how to tackle it might have been agreed-upon beforehand.
> 
> +1
> 
> [...snip...]
> 
> On 01/05/14 19:06, Samuli Seppänen wrote:
>> Lack of developer time is the biggest issue for us, and that lack of
>> time results in unnecessary work having to be done later; like having
>> and maintaining a patch tracking page instead of just handling the
>> patches immediately as they are sent to the list.
> 
> +1 ... For some more info to Timothe, I used to be quite active for a long 
> time.  But I almost "hit the wall" late last summer, and had to pull the 
> emergency break and reduce my workload.  I simply did too much and OpenVPN 
> was 
> one of the things which took quite some time for me.  I've not resigned 
> completely, but I'm incredibly grateful Gert was able to pick up where I had 
> to drop.  Gert has done an amazing job, far better than I could ever do!  
> I'll 
> come back somehow, and I even have a few patches on the ML which lingers too 
> - 
> but I need to step carefully forward.  But these patches which already are on 
> the ML does need help to get tested and reviewed.
> 
> We're really lacking developer time.  And developers often needs to also try 
> to keep track of what happens a few places too.  So this is a bad circle, as 
> to where to put the efforts today.  So I'm open to discuss a way to move this 
> patch tracking and some of the administrative work "away" from the 
> developers, 
> if anyone is available and have time and energy.  That's not something which 
> requires really deep developer skills, but interest and somewhat knowledge 
> about development is always good.  And it can be a good starting point to get 
> more involved in more core development with time as well, as it's a perfect 
> way to gain more knowledge about OpenVPN and how it works ... And if no-one 
> chimes in, things won't change all too much.
> 
> So the key point is probably: Do you dare to get your hands dirty?  Then 
> there 
> might absolutely be a possibility to join in :)
> 
> 
> -- 
> kind regards,
> 
> David Sommerseth
> 
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel



signature.asc
Description: Message signed with OpenPGP using GPGMail

[Openvpn-devel] [PATCH v2] Improve error reporting on file access to --client-config-dir and --ccd-exclusive

[David Sommerseth]

OpenVPN will do some simple sanity checking at startup to ensure the expected
files and directories is in place.  However, with --client-config-dir and
--ccd-exclusive, things are slightly different.  In both cases it is perfectly
fine that files does not exists, and we cannot know any file names beforehand
due to these filenames being based upon the certificate's CN field.

The problem arises when OpenVPN cannot open files inside a directory because
the directory permissions are too restrictive, have wrong ownership (triggered
by the usage of --user/--group) or other security mechanisms the OS uses.

When a client connects, the test_file() function is used to check if a client
config file has been prepared.  And if not, it continues without trying to read
it.  So, if the privileges of the running OpenVPN process is not allowed to
open and read an existing file, OpenVPN will treat this as a non-existing file
without saying anything.  This is clearly wrong.  So this patch adds an warning
message in the OpenVPN log if it could not open the file due to lack of
permissions.

This will work fine on all *nix based OSes.  Windows however reports 'no such
file or directory' (errno=2/-ENOENT) even on privilege access errors when the
directory this file resides is too restrictive.  But there is no easy way to
work around that.  However, I believe that the initial sanity checking at
startup will catch that one, as it will check if the directories it needs
exists.

This patch has only gone through simple basic testing, with both too few
privileges and with proper privileges to the CCD directory.  With wrong
privileges, the following error can be found if CN=Test client

  Fri May  2 00:00:10 2014 us=281993 127.0.0.1:41017 Could not access file 
'/etc/clients/Test client': Permission denied (errno=13)

[v2 - use openvpn_errno() instead of errno, for better platform support]

Trac: #277
Trac-URL: https://community.openvpn.net/openvpn/ticket/277
Signed-off-by: David Sommerseth 
---
 src/openvpn/misc.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c
index 7483184..63b4c1c 100644
--- a/src/openvpn/misc.c
+++ b/src/openvpn/misc.c
@@ -861,6 +861,12 @@ test_file (const char *filename)
  fclose (fp);
  ret = true;
}
+  else
+   {
+ if( openvpn_errno () == EACCES ) {
+   msg( M_WARN | M_ERRNO, "Could not access file '%s'", filename);
+ }
+   }
 }

   dmsg (D_TEST_FILE, "TEST FILE '%s' [%d]",
-- 
1.7.1

Re: [Openvpn-devel] ipv6 env vars to client scripts

[Samuel Thibault]

David Sommerseth, le Fri 02 May 2014 01:39:05 +0200, a écrit :
> On 17/04/14 14:07, Lev Stipakov wrote:
> > Hello,
> >
> > Are there any plans to support ipv6 env vars in
> > client-connect/disconnect scripts?
> >
> > There are at least 2 tickes on that feature:
> >
> > https://community.openvpn.net/openvpn/ticket/230
> > https://community.openvpn.net/openvpn/ticket/369
> >
> > Is there anything that prevents merging any of suggested patches to
> > the master branch?
> 
> I don't think I've seen these patches on the mailing list (I'm going through 
> the list now).

My patches were sent on 2013 May 24th on openvpn-devel.

Samuel

Re: [Openvpn-devel] ipv6 env vars to client scripts

[David Sommerseth]

[re-sending, with mailing list on Cc as well]

On 17/04/14 14:07, Lev Stipakov wrote:

Hello,

Are there any plans to support ipv6 env vars in
client-connect/disconnect scripts?

There are at least 2 tickes on that feature:

https://community.openvpn.net/openvpn/ticket/230
https://community.openvpn.net/openvpn/ticket/369

Is there anything that prevents merging any of suggested patches to
the master branch?


I don't think I've seen these patches on the mailing list (I'm going through 
the list now).  All patches must go via the mailing list for 
puopenvpn-users@lists.sourceforge.netblic ACK messages.  So it would be great 
if you could get these patches on the list, using git send-email.  It helps 
making the review process smoother.


Maybe the patches in both these two tickets could be merged into a single 
patch.  They look quite related.



--
kind regards,

David Sommerseth

Re: [Openvpn-devel] [PATCH] Fix bug that incorrectly refuses oid representation eku's in polar builds

[David Sommerseth]

On 25/04/14 10:41, Steffan Karger wrote:

The return value of x509_get_numeric_string() was interpreted incorrectly
by ssl_verify_polarssl.c's x509_verify_cert_eku(). This patch enables the
usage of oid represenation in --remote-cert-eku options.

Signed-off-by: Steffan Karger 
---
  src/openvpn/ssl_verify_polarssl.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/ssl_verify_polarssl.c 
b/src/openvpn/ssl_verify_polarssl.c
index 5db4f02..f2b0574 100644
--- a/src/openvpn/ssl_verify_polarssl.c
+++ b/src/openvpn/ssl_verify_polarssl.c
@@ -340,7 +340,7 @@ x509_verify_cert_eku (x509_cert *cert, const char * const 
expected_oid)
}
}

- if (0 == x509_oid_get_numeric_string( oid_num_str,
+ if (0 < x509_oid_get_numeric_string( oid_num_str,
  sizeof (oid_num_str), oid))
{
  msg (D_HANDSHAKE, "++ Certificate has EKU (oid) %s, expects %s",



ACK.

I've only glared at the code, and read the PolarSSL source code. 
x509_oid_get_numeric_string() is just calling oid_get_numeric_string() which says:


 * \return Length of the string written (excluding final NULL) or
 * POLARSSL_ERR_OID_BUF_TO_SMALL in case of error

So returning 0 is not necessarily a failure at all, and 
POLARSSL_ERR_OID_BUF_TO_SMALL is a negative number (-0x00B).



--
kind regards,

David Sommerseth