Re: [Openvpn-devel] [PATCH] Serial number export, better

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/04/10 13:20, Davide Brini wrote:
> contrib/OCSP_check/OCSP_check.sh:
>  New barebone script to demonstrate how to use $tls_serial_{n}
>  to perform simple OCSP queries using OpenSSL command line
>  "openssl ocsp". Minimal sanity checks to fail if user tries to
>  use it without customizing.
> 
> openvpn.8:
>  Added some notes about $tls_serial_{n} format and usage to the
>  existing description.
> 
> ssl.c:
>  correctly manage and export serial numbers of any size (as
>  parsed by OpenSSL) into the environment. Set to empty string
>  in case of errors, as 0 and negative numbers are all possible
>  (although illegal) certificate serial numbers. Use an OpenSSL
>  BIO object to do the job. Conforms to coding style guidelines.
> 
> See the discussion at
> 
> http://article.gmane.org/gmane.network.openvpn.devel/3588
> 
> for more details.
> 
> Signed-off-by: Davide Brini 
> ---
>  contrib/OCSP_check/OCSP_check.sh |   89 
> ++
>  openvpn.8|7 +++-
>  ssl.c|   27 ++-
>  3 files changed, 119 insertions(+), 4 deletions(-)
>  create mode 100644 contrib/OCSP_check/OCSP_check.sh
> 

This patch is now applied to the bugfix2.1 branch and merged into
allmerged.  An updated tree is now available.
Commit fa47f0a36c2aeda972a94c93f8f83246306812a0


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvXXhEACgkQDC186MBRfrqp6QCfSroMqJRTJ3xdZIHab2YMBxhE
TyoAoIgoym231GFcjDNhk9+Z5+WdMltx
=OtJi
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PULL-REQUEST v3] VLAN-Tagging

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/04/10 16:39, Fabian Knittel wrote:
> Hi,
> 
> changes since the last round of patches:
> 
>  - Added Signed-Off-By to all patches.
> 
>  - Properly mentioned "--vlan-accept all" mode in options.c (it was
>missing in a few places).
> 
>  - Split out '--vlan-accept raw' to '--vlan-tagging' boolean switch.
>Quoting from the patch description:
> 
>> As '--vlan-accept raw' is a global behavioural modifier, it makes more 
>> sense
>> to break it out into a global '--vlan-tagging' boolean switch. (Which
>> matches the approach chosen in the initial patch-set.)
>>
>> '--vlan-accept tagged|untagged|all' now only specifies the behaviour of 
>> the
>> tap device, while '--vlan-tagging' specifies whether OpenVPN should take 
>> a
>> closer look at the tagging of packets.
>>
>> The patch is only a configuration option change.  The behaviour should
>> remain the same.
>>
>>   New   Old
>>   --
>>
>>   not specifying anything is equivalent to not specifying anything
>>
>>   not specifying anything is equivalent to '--vlan-accept raw'
>>
>>   '--vlan-tagging' +
>>   '--vlan-accept tagged'  is equivalent to '--vlan-accept tagged'
>>
>>   '--vlan-tagging' +
>>   '--vlan-accept untagged' is equivalent to '--vlan-accept untagged'
>>
>>   '--vlan-tagging'is equivalent to '--vlan-accept all'
>>
>>   '--vlan-tagging' +
>>   '--vlan-accept all' is equivalent to '--vlan-accept all'
> 
> All further work will be bug-fix only.
> 
> 
> The rebased changes are available from my git repo [1] on branch
> 'feat_vlan'. On branch 'feat_vlan_tagging' the same changes are
> available as incremental patches to the 'feat_vlan_tagging' branch on
> openvpn-testing.git. (Only the non-incremental patches provide all
> missing Signed-Off-Bys).
> 
> For reviewers who haven't had a look at the other patches yet, I've
> attached a diff containing all changes introduced by the current patch-set.
> 
> Cheers
> Fabian
> 
> 1: git://fsmi-dev.fsmi.uni-karlsruhe.de/openvpn.git

Hi Fabian!

I've finally found some time to dig into this again.  After some
consideration, I decided to rebase your work on your feat_vlan_tagging
branch against the openvpn-testing.git feat_vlan_tagging branch.

This means that your earlier patches without signed-off-by tags are not
merged in.  I am fine with that, as I've become stricter on those tags
later on.

The alternative is to scratch the feat_vlan_tagging branch now in
openvpn-testing.git and re-establish it on your feat_vlan branch, which
has those tags all from the beginning.

So I will leave it up to you now how you want it.  But in the moment I
this branch gets merged into allmerged, its too late to change your
opinion.  I will wait for your reply on which approach you would like.

When this is settled, the only missing thing is to get someone who can
understand the code path being changed in your feature branch a bit
better than me to give an official ACK.  When I get that ACK, it goes
into allmerged.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvXXZYACgkQDC186MBRfrqSDQCggVagtu6pM/1hp+QdvYyL8Pcv
hfIAoJ7jIJWgN5Dt86EfQLjc6i1YhbQ1
=X4FI
-END PGP SIGNATURE-

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/27/2010 05:58:43 AM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > IMO OpenVPN is encouraging bad practices by supplying packages for
> > distros that include OpenVPN.
> 
> Ideally the package for that distro as made by OpenVPN is always
> equivalent to the one made by the distributor.
> 
> What do I mean? I mean that I'm happy with .spec files and the likes,
> that make up the source code for a particular kind of binary package,
> being committed upstream.
> 
> And if they are, then it's of course fairly easy for upstream to use
> them, and to make packages which are at the very least compatible
> with the distribution.

I agree.
It is useful for OpenVPN to distribute .spec files and
equivalents for use by disto packagers.

> 
> And, I think that since it is downloaded from a site other than the
> distributor's, users who actually do grab packages "manually" will be
> able to tell the difference from a package delivered by the
> distributor.

The question is not whether users can tell the difference, it's
whether users know enough to know the advantages of getting
their packages from their distro.  I believe that most users
are unaware of these advantages because they have experience 
only with OSs that force them to arrange for their own 
systems integration.  IMO the widespread failure to integrate disparate
software and the consequent gradual degradation of so many systems,
often ending in a disk wipe and OS re-install, demonstrates
the extent of the problem.  While OpenVPN's users are clearly
the cream of the crop, hip, techo-savvy, and sporting
shiny white smiles, I don't believe they are immune
and the OpenVPN project should encourage them to make
good choices.  This would help toward a good long-term
OpenVPN experience.  The current policy that makes
pre-packaged downloads available without explanation
does nothing to encourage good sysadmin practice and
puts a bad choice one click away.

Giant problem?  No.  They'll always be plenty of ways
to make bad choices. I'd be ok with making distro specific packages 
available so long as you also tell the end-user they are 
probably better off without them.  :)

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] Serial number export, better

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/04/10 13:20, Davide Brini wrote:
> contrib/OCSP_check/OCSP_check.sh:
>  New barebone script to demonstrate how to use $tls_serial_{n}
>  to perform simple OCSP queries using OpenSSL command line
>  "openssl ocsp". Minimal sanity checks to fail if user tries to
>  use it without customizing.
> 
> openvpn.8:
>  Added some notes about $tls_serial_{n} format and usage to the
>  existing description.
> 
> ssl.c:
>  correctly manage and export serial numbers of any size (as
>  parsed by OpenSSL) into the environment. Set to empty string
>  in case of errors, as 0 and negative numbers are all possible
>  (although illegal) certificate serial numbers. Use an OpenSSL
>  BIO object to do the job. Conforms to coding style guidelines.
> 
> See the discussion at
> 
> http://article.gmane.org/gmane.network.openvpn.devel/3588
> 
> for more details.
> 
> Signed-off-by: Davide Brini 
> ---
>  contrib/OCSP_check/OCSP_check.sh |   89 
> ++
>  openvpn.8|7 +++-
>  ssl.c|   27 ++-
>  3 files changed, 119 insertions(+), 4 deletions(-)
>  create mode 100644 contrib/OCSP_check/OCSP_check.sh
> 

ACK!  This is looking good!  I've put it into my work queue and will try
to get time sometime this week to get it into the bugfix2.1 branch.

Thanks a lot for your hard work on this one!


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvW/KwACgkQDC186MBRfrqUNACfRKjQww+GT1Pf3whbN5a8xr04
2hEAn2p0z1jg9nWYfg7oadIEFWkk5tgD
=juOA
-END PGP SIGNATURE-

[Openvpn-devel] [PATCH] Serial number export, better

[Davide Brini]

contrib/OCSP_check/OCSP_check.sh:
 New barebone script to demonstrate how to use $tls_serial_{n}
 to perform simple OCSP queries using OpenSSL command line
 "openssl ocsp". Minimal sanity checks to fail if user tries to
 use it without customizing.

openvpn.8:
 Added some notes about $tls_serial_{n} format and usage to the
 existing description.

ssl.c:
 correctly manage and export serial numbers of any size (as
 parsed by OpenSSL) into the environment. Set to empty string
 in case of errors, as 0 and negative numbers are all possible
 (although illegal) certificate serial numbers. Use an OpenSSL
 BIO object to do the job. Conforms to coding style guidelines.

See the discussion at

http://article.gmane.org/gmane.network.openvpn.devel/3588

for more details.

Signed-off-by: Davide Brini 
---
 contrib/OCSP_check/OCSP_check.sh |   89 ++
 openvpn.8|7 +++-
 ssl.c|   27 ++-
 3 files changed, 119 insertions(+), 4 deletions(-)
 create mode 100644 contrib/OCSP_check/OCSP_check.sh

diff --git a/contrib/OCSP_check/OCSP_check.sh b/contrib/OCSP_check/OCSP_check.sh
new file mode 100644
index 000..2ffe5d6
--- /dev/null
+++ b/contrib/OCSP_check/OCSP_check.sh
@@ -0,0 +1,89 @@
+#!/bin/sh
+
+# Sample script to perform OCSP queries with OpenSSL
+# given a certificate serial number.
+
+# If you run your own CA, you can set up a very simple
+# OCSP server using the -port option to "openssl ocsp".
+
+# Full documentation and examples:
+# http://www.openssl.org/docs/apps/ocsp.html
+
+
+# Edit the following values to suit your needs
+
+# OCSP responder URL (mandatory)
+# YOU MUST UNCOMMENT ONE OF THESE AND SET IT TO A VALID SERVER
+#ocsp_url="http://ocsp.example.com/;
+#ocsp_url="https://ocsp.secure.example.com/;
+
+# Path to issuer certificate (mandatory)
+# YOU MUST SET THIS TO THE PATH TO THE CA CERTIFICATE
+issuer="/path/to/CAcert.crt"
+
+# use a nonce in the query, set to "-no_nonce" to not use it
+nonce="-nonce"
+
+# Verify the response
+# YOU MUST SET THIS TO THE PATH TO THE RESPONSE VERIFICATION CERT
+verify="/path/to/CAcert.crt"
+
+# Depth in the certificate chain where the cert to verify is.
+# Set to -1 to run the verification at every level (NOTE that
+# in that case you need a more complex script as the various
+# parameters for the query will likely be different at each level)
+# "0" is the usual value here, where the client certificate is
+check_depth=0
+
+cur_depth=$1 # this is the *CURRENT* depth
+common_name=$2   # CN in case you need it
+
+# minimal sanity checks
+
+err=0
+if [ -z "$issuer" ] || [ ! -e "$issuer" ]; then
+  echo "Error: issuer certificate undefined or not found!" >&2
+  err=1
+fi
+
+if [ -z "$verify" ] || [ ! -e "$verify" ]; then
+  echo "Error: verification certificate undefined or not found!" >&2
+  err=1
+fi
+
+if [ -z "$ocsp_url" ]; then
+  echo "Error: OCSP server URL not defined!" >&2
+  err=1
+fi
+
+if [ $err -eq 1 ]; then
+  echo "Did you forget to customize the variables in the script?" >&2
+  exit 1
+fi
+
+# begin
+if [ $check_depth -eq -1 ] || [ $cur_depth -eq $check_depth ]; then
+  eval serial="\$tls_serial_${cur_depth}"
+
+  # Check that the serial is not empty
+  if [ -n "$serial" ]; then
+
+# This is only an example; you are encouraged to run this command (without
+# redirections) manually against your or your CA's OCSP server to see how
+# it responds, and adapt accordingly.
+# Sample output:
+#
+# Response verify OK
+# 0x428740A5: good
+#  This Update: Apr 24 19:38:49 2010 GMT
+#  Next Update: May  2 14:23:42 2010 GMT
+
+openssl ocsp -issuer "$issuer" \
+ "$nonce" \
+ -CAfile "$verify" \
+ -url "$ocsp_url" \
+ -serial "0x${serial}" >/dev/null 2>&1
+  else
+exit 1
+  fi
+fi
diff --git a/openvpn.8 b/openvpn.8
index 45e61fa..a31596a 100644
--- a/openvpn.8
+++ b/openvpn.8
@@ -5321,7 +5321,12 @@ where
 is the verification level.  Only set for TLS connections.  Set prior
 to execution of
 .B --tls-verify
-script.
+script. This is in the form of a hex string like "37AB46E0", which is
+suitable for doing serial-based OCSP queries (with OpenSSL, you have
+to prepend "0x" to the string). If something goes wrong while reading
+the value from the certificate it will be an empty string, so your
+code should check that.
+See the contrib/OCSP_check/OCSP_check.sh script for an example.
 .\"*
 .TP
 .B tun_mtu
diff --git a/ssl.c b/ssl.c
index 1b275af..68a3e3b 100644
--- a/ssl.c
+++ b/ssl.c
@@ -788,9 +788,30 @@ verify_callback (int preverify_ok, X509_STORE_CTX * ctx)

   /* export serial number as environmental variable */
   {
-const int serial = 

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Peter Stuge]

Karl O. Pinc wrote:
> IMO OpenVPN is encouraging bad practices by supplying packages for
> distros that include OpenVPN.

Ideally the package for that distro as made by OpenVPN is always
equivalent to the one made by the distributor.

What do I mean? I mean that I'm happy with .spec files and the likes,
that make up the source code for a particular kind of binary package,
being committed upstream.

And if they are, then it's of course fairly easy for upstream to use
them, and to make packages which are at the very least compatible
with the distribution.

And, I think that since it is downloaded from a site other than the
distributor's, users who actually do grab packages "manually" will be
able to tell the difference from a package delivered by the
distributor.


//Peter

[Openvpn-devel] OpenVPN 2.1.1 and "inactive". "ping" is retrigger the inactivity timeout!!

[Siegfried Müller - MB Connect Line GmbH]

>> On 22/04/10 18:40, Siegfried Müller - MB Connect Line GmbH wrote:
>> Hi developers,
>> 
>> does anyone tried the "inactive" option with the openvpn version 2.1.1?
>> I step up from 2.0.1 to 2.1.1 and get the problem, that the client does not 
>> disconnect after inactivity.
>> If i set the option "ping 0" instead of "ping 10" the inactivity works. 
>> Could that be a problem, that the new version does retrigger the 
>> inactivity-timeout with his own ping?
>> any ideas?
>> 

> Having just poked quickly at the code, it seems that "ping 0" disables the 
> pinging completely.  As a ping packet will cause traffic on the tunnel, the 
> connection will > then not be inactive.  If it worked differently on OpenVPN 
> 2.0, I can understand you are surprised.
> 
> On the other hand, how the code now looks like, this seems to be the expected 
> behaviour in OpenVPN 2.1.  So using --ping would disable the
> - --inactive feature indirectly.
> 
> If this was an intended change or not, that I do not know.  But I'll try to 
> remember to mention it on the developers meeting today.
> 
> 
> kind regards,
> 
> David Sommerseth

well, i think openvpn should ignore the own pings for retrigger the inactivity 
timeout. Otherwise, you have to know to set --ping 0 if you want to use 
--inactive and also in this case the server could not recognize the 
disconnected client. Currently the client ignores incoming vpn-pings and did 
not retrigger the inactivity, why only incoming?
kind regards,
Siegfried

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Toby Thain]

On 27-Apr-10, at 1:54 PM, Karl O. Pinc wrote:


On 04/26/2010 09:46:06 PM, Toby Thain wrote:


On 27-Apr-10, at 12:19 PM, Karl O. Pinc wrote:


On 04/26/2010 06:19:31 PM, Toby Thain wrote:





I don't think unpackaged OS X binaries are very useful, which is

why

I

created the pkg+dmg.


I agree, because the Apple development kit is shipped,
if not installed, on every Mac.


It ships on the DVD but most people never install it, of course.


(Last I looked.)  And
because ./configure ; make is painless.


To use your argument from above -- imho much too complex for most end

users. As well as requiring Apple Developer Tools (they have to go
find the original DVD, which may or may not even be possible), this
involves locating and downloading two source archives from two
different sites, and configuring and building them both; beyond the
pale for non-technical users, even though it's trivial for "us".


I'm not following you here.  I thought we were talking about whether
unpackaged OS/X binaries were useful to anybody.  The answer being
no because developers and packagers are the only people who need
them and developers and packagers can easily create OS/X binaries.


Ah, okay, then we are in agreement.




...



It seems logical to me that an OS X binary dmg could be on the
OpenVPN

downloads page, giving a similar level of convenience to "yum install

openvpn" or "apt-get install openvpn" or "emerge openvpn".


Sure.  Packages can be useful to end-users.


Right - or those organising deployments to them.





One thing that should *not*, in my opinion, be encouraged at all by
OpenVPN, are third party package managers (MacPorts, Fink, Homebrew
etc) as the binary route on OS X. That seems to do more harm than
good.


I have no opinion.  I suppose it depends on the degree of systems
integration provided by the 3rd party.  I assume this is usually
none, in which case there's no point and the end-user may as well
get their packages straight from the source.




If I were deploying it, rather than hacking on it, I would expect a
binary installer to be available for my platform, at
http://openvpn.net


I'd expect my distro provider to supply it, be sure it integrates
with everything else, and support security fixes. ... The typical  
user is more likely to have

a bad OpenVPN experience, over time, when using packages
obtained directly from OpenVPN than when using packages
created by their distro, for the reasons outlined above
and earlier in this thread. ...

The situation is different for MS Windows and OS/X.
Packages are needed for those platforms and whatever
other commercial OSs the project wants to support.


+1
Solaris 10 is another possibility. I have experience with this package  
flavour and could easily do the same job as I did for OS X, for  
contrib, at least, if not binary pkg.





There.  Now I've wandered far from the original
topic and likely offended someone too.


Certainly not me.

--Toby


Mission accomplished.  :-P

Regards,


Karl 
Free Software:  "You don't pay back, you pay forward."
-- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 02:11:26 PM, Karl O. Pinc wrote:
> On 04/26/2010 11:53:19 AM, Peter Stuge wrote:
> > Karl O. Pinc wrote:
> > > the project is already releasing unpackaged Linux
> > > binaries
> > 
> > Really?
> 
> They seem to have stopped sometime after July 30 2008.
> 
> http://web.archive.org/web/20080730205524/openvpn.net/index.php/
> downloads.html

Sheesh Peter, you are right.  That pages has source downloads
and a MS Windows installer.  And it's the same page I recall
seeing forever.

Nothing anywhere about non-MSWindows binaries.

I completely mis-remembered, and didn't even see my mistake
when I called up the old page.  Sorry about that.

I seem to be making a habit of making false statements
on this list.  I'll see if I can fix that.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 09:46:06 PM, Toby Thain wrote:
> 
> On 27-Apr-10, at 12:19 PM, Karl O. Pinc wrote:
> 
> > On 04/26/2010 06:19:31 PM, Toby Thain wrote:
> >>>
> >>>
> >>
> >> I don't think unpackaged OS X binaries are very useful, which is
> why
> >> I
> >>
> >> created the pkg+dmg.
> >
> > I agree, because the Apple development kit is shipped,
> > if not installed, on every Mac.
> 
> It ships on the DVD but most people never install it, of course.
> 
> >  (Last I looked.)  And
> > because ./configure ; make is painless.
> 
> To use your argument from above -- imho much too complex for most end 
> 
> users. As well as requiring Apple Developer Tools (they have to go  
> find the original DVD, which may or may not even be possible), this  
> involves locating and downloading two source archives from two  
> different sites, and configuring and building them both; beyond the  
> pale for non-technical users, even though it's trivial for "us".

I'm not following you here.  I thought we were talking about whether
unpackaged OS/X binaries were useful to anybody.  The answer being
no because developers and packagers are the only people who need 
them and developers and packagers can easily create OS/X binaries.

> 
> The pkg/dmg is, on the other hand, a genuine one click install. (Even 
> 
> if you have to do a 2nd key install, which pkg has to be built  
> individually and distributed securely anyway.)

Depending on the degree of security required it could be enough
to key the server but not the client.  It does not matter to
my argument though, if you're going to make individualized packages
for each user you may as well put everything required into
the package you supply.  Having to compile binaries for MS Windows
becomes a big sticking point when making an all-inclusive MS
Windows installer; because you're already making an installer
you know how to do that and you've got a working example
of the OpenVPN installer as a starting point.

> It seems logical to me that an OS X binary dmg could be on the 
> OpenVPN
>  
> downloads page, giving a similar level of convenience to "yum install 
> 
> openvpn" or "apt-get install openvpn" or "emerge openvpn".

Sure.  Packages can be useful to end-users.

> 
> One thing that should *not*, in my opinion, be encouraged at all by  
> OpenVPN, are third party package managers (MacPorts, Fink, Homebrew  
> etc) as the binary route on OS X. That seems to do more harm than
> good.

I have no opinion.  I suppose it depends on the degree of systems
integration provided by the 3rd party.  I assume this is usually
none, in which case there's no point and the end-user may as well
get their packages straight from the source.

> 
> 
> If I were deploying it, rather than hacking on it, I would expect a  
> binary installer to be available for my platform, at
> http://openvpn.net

I'd expect my distro provider to supply it, be sure it integrates
with everything else, and support security fixes.  YMMV.
Of course this assume a distro.  Users of commercial OSs
are generally expected to arrange for their own systems
integration and application support.  In that case the
typical user should follow your advice and get their
packages direct from OpenVPN.

Which raises another issue.  IMO OpenVPN is encouraging
bad practices by supplying packages for distros that
include OpenVPN.  The typical user is more likely to have
a bad OpenVPN experience, over time, when using packages
obtained directly from OpenVPN than when using packages
created by their distro, for the reasons outlined above
and earlier in this thread.  Some people may benefit
from having the most recent OpenVPN and obtaining it
straight from the project, but these people are also
the most likely to be able to package it themselves.
If this is all true then the OpenVPN project is doing
it's userbase a dis-service by making, say, packages
for Red Hat available for download because this is
tacit encouragement of bad practice.  At minimum
there should be a warning to educate the naive user.

The situation is different for MS Windows and OS/X.
Packages are needed for those platforms and whatever
other commercial OSs the project wants to support.

There.  Now I've wandered far from the original
topic and likely offended someone too.
Mission accomplished.  :-P

Regards,


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Toby Thain]

On 27-Apr-10, at 12:46 PM, Toby Thain wrote:



On 27-Apr-10, at 12:19 PM, Karl O. Pinc wrote:


On 04/26/2010 06:19:31 PM, Toby Thain wrote:





I don't think unpackaged OS X binaries are very useful, which is why
I

created the pkg+dmg.


I agree, because the Apple development kit is shipped,
if not installed, on every Mac.


It ships on the DVD but most people never install it, of course.


(Last I looked.)  And
because ./configure ; make is painless.


To use your argument from above -- imho much too complex for most end
users. As well as requiring Apple Developer Tools (they have to go
find the original DVD, which may or may not even be possible), this
involves locating and downloading two source archives from two
different sites, and configuring and building them both;


I left out some other items that the package includes:
– the XML service metadata (plist) that doesn't exist in the source  
distribution

– launchd service setup

So it's really well beyond the "end user" realm...

(More details: http://telegraphics.com.au/svn/openvpn-package/trunk/README 
 )


This is probably solved in other ways by 3rd party OpenVPN derivatives  
out there, but imho there should still be an 'official' binary  
installer.


--Toby


beyond the
pale for non-technical users, even though it's trivial for "us".

The pkg/dmg is, on the other hand, a genuine one click install.

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Toby Thain]

On 27-Apr-10, at 12:19 PM, Karl O. Pinc wrote:


On 04/26/2010 06:19:31 PM, Toby Thain wrote:





I don't think unpackaged OS X binaries are very useful, which is why
I

created the pkg+dmg.


I agree, because the Apple development kit is shipped,
if not installed, on every Mac.


It ships on the DVD but most people never install it, of course.


 (Last I looked.)  And
because ./configure ; make is painless.


To use your argument from above -- imho much too complex for most end  
users. As well as requiring Apple Developer Tools (they have to go  
find the original DVD, which may or may not even be possible), this  
involves locating and downloading two source archives from two  
different sites, and configuring and building them both; beyond the  
pale for non-technical users, even though it's trivial for "us".


The pkg/dmg is, on the other hand, a genuine one click install. (Even  
if you have to do a 2nd key install, which pkg has to be built  
individually and distributed securely anyway.)
It seems logical to me that an OS X binary dmg could be on the OpenVPN  
downloads page, giving a similar level of convenience to "yum install  
openvpn" or "apt-get install openvpn" or "emerge openvpn".


One thing that should *not*, in my opinion, be encouraged at all by  
OpenVPN, are third party package managers (MacPorts, Fink, Homebrew  
etc) as the binary route on OS X. That seems to do more harm than good.




MS Windows on
the other hand requires additional software
to compile anything.  And the FOSS choices, which
are the the ones most universally available, are non-trivial
to install and use.

I'd bet cross compiling  Un*x-to-Mac is easier too, but
I have no experience to back that up.


Generally very simple, fwiw. It probably helps that OS X toolchain is  
gcc-based and many GNU utilities are standard.




Now that OpenVPN is accepting more patches cross compiling
Un*x-to-MSWindows will probably get easier but it will
never be easy.


If I were deploying it, rather than hacking on it, I would expect a  
binary installer to be available for my platform, at http://openvpn.net


--Toby



Karl 
Free Software:  "You don't pay back, you pay forward."
-- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 06:02:46 PM, David Sommerseth wrote:
> On 26/04/10 21:11, Karl O. Pinc wrote:
> > On Debian all I had to do was "aptitude install nsis" and then
> > run it to make MS Windows installers.  Plug and play, no
> > compiling necessary.
> >
> 
> Just a little nitpick, when you run makensis, that's actually
> compilation of the installer - even when you're doing it on Linux. 
> You
> get a Windows binary as the result.

As long as we're nitpicking... ;-)

That's interesting.  I figured the nsis install scripts
were interpreted and, if I thought about it at all,
running makensis setup some data structures and did
some linking.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 06:19:31 PM, Toby Thain wrote:
> 
> On 27-Apr-10, at 1:58 AM, Karl O. Pinc wrote:
> >
> > The problem addressed is that there only binaries available
> > for MS Windows are pre-packaged in an installer executable.
> > This means that anyone who wants stock binaries but a
> > modified installer has to recompile from source.
> 
> For the OS X package, I chose to simply make two packages - one the  
> generic binaries, and one for whatever configuration and keys are  
> needed for a particular deployment. Could you do the same on Windows?

Sure, but this greatly increases the complexity for the
end-user.  Just adding another installer at least doubles the
complexity.  A custom install can be one-click.  The stock
OpenVPN installer (last I looked) presented the user
with many choices and is far more complex than a 1-click
install.

Getting the users to do anything at all can be tricky
(especially at the outlying ends of the pay scale).
The less that can go wrong the better.

> > But this only makes sense if OpenVPN _will_ release
> > unpackaged MS Windows binaries.  It makes sense to me;
> > the project is already releasing unpackaged Linux
> > binaries and it now talking about doing the same
> > for OS/X binaries.
> 
> I don't think unpackaged OS X binaries are very useful, which is why 
> I
>  
> created the pkg+dmg. 

I agree, because the Apple development kit is shipped,
if not installed, on every Mac.  (Last I looked.)  And
because ./configure ; make is painless.  MS Windows on
the other hand requires additional software 
to compile anything.  And the FOSS choices, which
are the the ones most universally available, are non-trivial
to install and use.  

I'd bet cross compiling  Un*x-to-Mac is easier too, but 
I have no experience to back that up.
Now that OpenVPN is accepting more patches cross compiling
Un*x-to-MSWindows will probably get easier but it will
never be easy.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Toby Thain]

On 27-Apr-10, at 5:11 AM, Karl O. Pinc wrote:


On 04/26/2010 11:53:19 AM, Peter Stuge wrote:

Karl O. Pinc wrote:

the project is already releasing unpackaged Linux
binaries


Really?


They seem to have stopped sometime after July 30 2008.

http://web.archive.org/web/20080730205524/openvpn.net/index.php/
downloads.html

It's hard to tell when because archive.org does not appear
to be allowed to archive the site any longer.  Or at least
there's nothing more recent.  (This seems silly.  I wonder why.)

(I clearly haven't been downloading binaries in a while.
Probably because I rely on my distro for binaries so
they can do the systems integration and security patches,
or I am getting development from CVS/git.

IMO people who don't rely on their distro for systems integration
and security patches are asking for trouble.  There are of course
always reasons to make specific exceptions, RH comes to mind. :)

Is OpenVPN in RHEL6?)




and it now talking about doing the same for OS/X binaries.


Recently discussed work for contrib/ produces a .dmg, very much a
package in my view.


Ok.  I don't know much about .dmg.  I thought they were basically
tarballs by another name in that they just stick stuff somewhere.
My Mac usage is sporadic, sorry.



The Makefile produces both 'pkg' and 'dmg'. Dmg is just an OS X  
standard self-mounting single file archive which is a way of  
distributing the pkg. Generating a dmg is useful because the pkg is  
actually a file tree, not a single file, so inappropriate for  
downloading, attaching, etc.


Pkg is the package itself, which like any binary UNIX package is  
indeed a tarball by another name plus some metadata and scripts - but  
of course infinitely easier for non-technical end users (let alone  
compared to a source build).


--Toby








There's clear utility.


I guess it depends. I'm not sure that I agree that compilation is a
much bigger bother than (cross-)compiling the NSIS installer..


On Debian all I had to do was "aptitude install nsis" and then
run it to make MS Windows installers.  Plug and play, no
compiling necessary.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
-- Robert A. Heinlein


--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Toby Thain]

On 27-Apr-10, at 1:58 AM, Karl O. Pinc wrote:


On 04/26/2010 10:23:21 AM, David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/04/10 16:47, Karl O. Pinc wrote:

Speaking of the standard release process there is still this

thread:


Re: [Openvpn-devel] Unpackged Windows binaries? -- Problems

building


2.1 rc15 on Windows XP

and its patch for releasing unpackaged MS Windows binaries;
quite similar to what you're proposing for OS/X.



Thanks for pushing this.  I am honestly not quite sure were we stand
with that patch.  And since I understand the Windows building least
of
all, I've refrained from going into details of this one so far.  It
has
not been my intention of ignoring this patch.  I'm primarily focusing
on
the platforms I happen to understand better, and hope others will
chime
in on the other issues.

But as responses are missing, I'll try to find some time in the near
future (this week is crazily hectic for me) - to see if I can
understand
what your patch solves.  That is a little bit unclear to me, as the
patch I'm looking at seems to just make a tarball with compiled
binaries
... Right now, I do not immediately see what problem that solves.
But
I'm pretty sure I'm overlooking something!

Btw, you mentioned in some of the threads that you would look at some
of
the docs for this as well.  I remember vaguely something about
another
set of patches for HTML files - which I can't say I've seen in the
source tree.  That would be good to get into the tree together with
this
patch when I've looked at it a bit better.


It's a packaging policy issue.

The problem addressed is that there only binaries available
for MS Windows are pre-packaged in an installer executable.
This means that anyone who wants stock binaries but a
modified installer has to recompile from source.

There are many reasons why one would want a non-stock
MS Windows installer -- the foremost being to include
an OpenVPN configuration file that allows connections
between pre-designated endpoints.  One might want to
go so far as to include certificates in the installation
to secure the communications channel.  ;-)


For the OS X package, I chose to simply make two packages - one the  
generic binaries, and one for whatever configuration and keys are  
needed for a particular deployment. Could you do the same on Windows?



Creating custom installation executables is
relatively easy, especially as the OpenVPN code base
includes a working config file that's used to make
the installer OpenVPN distributes.  But of course
OpenVPN binaries are a requirement before packaging
can be attempted.

Recompiling is both complicated and error prone.  Historically
there are a number of issues that make compiling difficult.
I recall problems with mingw versions
when compiling on MS Windows and some other sort of problems
when trying to cross compile from Linux.


Just a FYI - the Visual Studio Express toolchain (32+64 bit) works  
well under WINE.



In any case it's
clear that compiling will always be relatively complicated
and time-consuming to setup in comparison with downloading
binaries.


Correct - while it is a lot easier on OS X (just ./configure; make),  
most users never install the Developer Tools and don't know how to use  
Terminal. So we have similar motivations.




So, there are 2 patches.  The first is to the OpenVPN
build process.  It produces unpackaged MS Windows binaries
and (last you wrote) it works.  The second patch is to
the OpenVPN documentation.  It documents that the
binaries exist and when you want them.  It does not
apply because the OpenVPN website has since been
restructured.   The doc patch needs to be re-worked
to put the text in the appropriate place.

But this only makes sense if OpenVPN _will_ release
unpackaged MS Windows binaries.  It makes sense to me;
the project is already releasing unpackaged Linux
binaries and it now talking about doing the same
for OS/X binaries.


I don't think unpackaged OS X binaries are very useful, which is why I  
created the pkg+dmg. I haven't explored whatever GUI & packaging  
enhancements have been done by third parties - overkill for my  
immediate simple deployment needs.


I *do* think that generic OS X binary pkgs are worthwhile including as  
part of the standard downloads.


--Toby


There's clear utility.  Regardless,
this is a policy decision.  Getting a resolution on
packaging policy seems to me to be the first step.

If OpenVPN _won't'_ release unpackaged MS Windows
binaries I'd like to know why so it would be
nice if whomever moves this forward, as with
any other patch, solicits more than a yes/no answer.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
-- Robert A. Heinlein


--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/04/10 21:11, Karl O. Pinc wrote:
> On 04/26/2010 11:53:19 AM, Peter Stuge wrote:
>> Karl O. Pinc wrote:
[...snip...]
> IMO people who don't rely on their distro for systems integration
> and security patches are asking for trouble.  There are of course
> always reasons to make specific exceptions, RH comes to mind. :)
> 
> Is OpenVPN in RHEL6?)

Yes, I'm pretty sure it is.  RHEL5 even shipped OpenVPN 2.1_rc15 for a
long time as a stable release until OpenVPN released 2.1.1.  In
RHEL5.4/CentOS5.4, I'm pretty sure 2.1.1 is standard by now.

Those releases are also pretty much in sync with the upstream OpenVPN
release.  No extra security fixes which is not in OpenVPN - as it should
be, IMHO.  From what I've seen in the Fedora builds, it's mostly
distro-specific adjustments added on top of the OpenVPN 2.1.1 tarball.

But I agree that using a distro-based installation, gives you the
upgrades in a very convenient way.  Automatically - and you get a
reminder regularly.

>>> and it now talking about doing the same for OS/X binaries.
>>
>> Recently discussed work for contrib/ produces a .dmg, very much a
>> package in my view.
> 
> Ok.  I don't know much about .dmg.  I thought they were basically
> tarballs by another name in that they just stick stuff somewhere.
> My Mac usage is sporadic, sorry.
>
>>
>>> There's clear utility.
>>
>> I guess it depends. I'm not sure that I agree that compilation is a
>> much bigger bother than (cross-)compiling the NSIS installer..
> 
> On Debian all I had to do was "aptitude install nsis" and then
> run it to make MS Windows installers.  Plug and play, no 
> compiling necessary.
> 

Just a little nitpick, when you run makensis, that's actually
compilation of the installer - even when you're doing it on Linux.  You
get a Windows binary as the result.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvWG5YACgkQDC186MBRfro2bQCfX3H740h3QErt8+fzPlwVNekk
btIAn3RMwwuLQCfrrfe29SSW46nZP9Tp
=XOWD
-END PGP SIGNATURE-