Re: [Openvpn-devel] Preparing 2.4-beta1 upload to Debian (Experimental)
Thanks Arne! I'll fix this in the next upload. On Wed, Jan 04, 2017 at 07:21:07PM +0100, Arne Schwabe wrote: > Am 21.11.16 um 10:10 schrieb Alberto Gonzalez Iniesta: > > Hi, > > > > I'm preparing an upload to Debian Experimental of 2.4-beta1 in order to > > get the maximum exposition as possible. In the meantime I'd like to know > > your opinion on the following patch that I've been applying to Debian's > > package for some years: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=367716;filename=openvpn_367716.diff;msg=10 > > Fixing this: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716 > > > > Thanks, > > > > Alberto > > > > One thing I noticed. Debian still includes a "route_default_nil.patch". > That patch changes the man page to the command line help which is wrong. > > The correct thing is to change the command line (patch attached). > > Arne > From a88d8ba3e81ca34fc2675805a273cd85875c8973 Mon Sep 17 00:00:00 2001 > From: Arne Schwabe <a...@rfc2549.org> > Date: Wed, 4 Jan 2017 19:18:46 +0100 > Subject: [PATCH] Change command help to match man page and implementation > > --- > src/openvpn/options.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/openvpn/options.c b/src/openvpn/options.c > index bfedb6a..80143e6 100644 > --- a/src/openvpn/options.c > +++ b/src/openvpn/options.c > @@ -198,7 +198,7 @@ static const char usage_message[] = > " is established. Multiple routes can be specified.\n" > " netmask default: 255.255.255.255\n" > " gateway default: taken from --route-gateway or > --ifconfig\n" > -" Specify default by leaving blank or setting to > \"nil\".\n" > +" Specify default by leaving blank or setting to > \"default\".\n" > "--route-ipv6 network/bits [gateway] [metric] :\n" > " Add IPv6 route to routing table after connection\n" > " is established. Multiple routes can be specified.\n" -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
On Mon, Jan 02, 2017 at 03:26:46PM +0100, Gert Doering wrote: > Hi, > > On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez Iniesta wrote: > > I just got this [1] bug report on OpenVPN 2.4 threating all certs as > > expired when upgrading from 2.3. I find this quite weird, but until I have > > some time to test it I thought asking here would be faster. > > From the bug report: > > Mon Jan 2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: depth=0, > error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, > emailAddress=my@email > > "what the log says" :-) > > 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had some > built-in checking which only looked at revocations, while 2.4 leaves this > to the crypto library, and they check all fields more rigidly). > > Specifically, CRLs with an expired "next update" field are flagged as > "expired" by OpenSSL, while the built-in check in 2.3 did not. > > > Since this bit a few people already, I wonder how we could communicate > this better. > > gert > > Oh! I see. Thanks Gert!! I can/will add a note on the Debian package, but that has a limited audience. Cheers, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify
Hi there, I just got this [1] bug report on OpenVPN 2.4 threating all certs as expired when upgrading from 2.3. I find this quite weird, but until I have some time to test it I thought asking here would be faster. Thanks, Alberto [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849909 -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] OpenVPN 2.4.0 released
On Tue, Dec 27, 2016 at 04:16:15PM +0200, Samuli Seppänen wrote: > The OpenVPN community project team is proud to release OpenVPN 2.4.0. It > can be downloaded from here: > > <http://openvpn.net/index.php/open-source/downloads.html> > And it's been uploaded to Debian unstable now. If all goes well it'll be in Stretch in 10 days. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs
On Tue, Dec 06, 2016 at 01:36:04PM +0100, Arne Schwabe wrote: > Am 06.12.16 um 13:26 schrieb Gert Doering: > > The existing code can leak socket FDs to the "--up" script, which is > > not desired. Brought up by Alberto Gonzalez Iniesta, based on debian > > bug 367716. > > > > Since different sockets get create at different times, just moving the > > set_cloexec() to link_socket_init_phase1() is not good enough - so move > > the call into create_socket_(), so we will catch ALL socket > > creations, no matter when or under which conditions they will be > > created (SOCKS proxy socket, listening socket, ...). > > Patch looks good. ACK from me. I also looked at the port-share code path > but that part isn't touched by this commit. > Works for me (tm) I'm just waiting for the pkcs11-helper maintainer [1] to upload 2.4~rc1 to Debian. If he decides to build against OpenSSL 1.1 I'd have to remove PKCS #11 support from Debian's package in Stretch. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828506 -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Refactor setting close-on-exec for socket FDs
On Mon, Dec 05, 2016 at 09:05:04PM +0100, Gert Doering wrote: > Hi, > > On Mon, Dec 05, 2016 at 08:01:14PM +0100, Alberto Gonzalez Iniesta wrote: > > The patch, after being adjusted to the new source, is not working anymore: > > > > Mon Dec 5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad > > file descriptor (errno=9) > > Mon Dec 5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad > > file descriptor (errno=9) > > This is with "the debian patch", or with my alternate suggestion? > > (I'm not sure if my patch is actually good enough as I think it's not > fixing TCP "after accept" sockets yet - but some sort of initial feedback > would be good :) ) > > gert So sorry Gert, I didn't notice yours. I' try it and let you know about the result. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Refactor setting close-on-exec for socket FDs
On Wed, Nov 23, 2016 at 07:43:21PM +0100, Gert Doering wrote: > Hi, > > On Wed, Nov 23, 2016 at 11:20:18AM +0100, Gert Doering wrote: > > The existing code can leak socket FDs to the "--up" script, which is > > not desired. Brought up by Alberto Gonzalez Iniesta, based on debian > > bug 367716. > > I'm not sure if that patch is good enough yet. > > Arne brought up "port-share" - where we fork processes, so it needs to > be ensured that whatever that process needs is still working. > > In addition to that, we have "TCP server" processes, which create new > sockets not by calling socket() but by calling accept() on the listening > socket, which is not in one of thew set_cloexec() paths - but watch out, > *these* might be the ones needed for port-share. > > gert Hi, The patch, after being adjusted to the new source, is not working anymore: Mon Dec 5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad file descriptor (errno=9) Mon Dec 5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad file descriptor (errno=9) Mon Dec 5 19:39:34 2016 Exiting due to fatal error Mon Dec 5 19:39:34 2016 Exiting due to fatal error FAIL: t_cltsrv.sh 1 of 2 tests failed (1 test was not run) Please report to openvpn-us...@lists.sourceforge.net So I guess Debian's bug #367716 [1] will come back from the dead :-( with 2.4. Regards, Alberto [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716 -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Preparing 2.4-beta1 upload to Debian (Experimental)
On Mon, Nov 21, 2016 at 03:37:45PM +0100, David Sommerseth wrote: > On 21/11/16 14:32, Samuli Seppänen wrote: > > Il 21/11/2016 11:10, Alberto Gonzalez Iniesta ha scritto: > >> Hi, > >> > >> I'm preparing an upload to Debian Experimental of 2.4-beta1 in > >> order to get the maximum exposition as possible. In the meantime > >> I'd like to know your opinion on the following patch that I've > >> been applying to Debian's package for some years: > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=367716;filename=openvpn_367716.diff;msg=10 > >> > >> > Fixing this: > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716 > >> > >> Thanks, > >> > >> Alberto > > > > That bug report is mighty old, from 2008. I wonder if the problem > > still persists at all? > > I hope at least Arne can chime in on this one, as he has done > tremendous work on the socket code. And I'd be surprised if this > patch applies cleanly on top of our master branch. No, I doesn't. But I updated it to 2.4. Find it attached. > Yes, it's an old issue. But from my brief 3 minutes look at socket.c, > I'd say it looks like to me this is still needed. The explanation in > the patch makes sense. Yep, I think it's still needed. Regards, Alberto > -- > _______ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 Description: Set socket's FD_CLOEXEC flag before calling up script Moving the set_cloexec() call from link_socket_init_phase2() to link_socket_init_phase1(). Author: Julien Cristau <jcris...@debian.org> Bug-Debian: http://bugs.debian.org/367716 Index: openvpn/src/openvpn/socket.c === --- openvpn.orig/src/openvpn/socket.c 2016-11-21 09:58:03.562096178 +0100 +++ openvpn/src/openvpn/socket.c 2016-11-21 10:01:20.143091482 +0100 @@ -1625,6 +1625,10 @@ } resolve_remote (sock, 1, NULL, NULL); } + + /* set socket file descriptor to not pass across execs, so that + scripts don't have access to it */ + set_cloexec (sock->sd); } static @@ -1677,10 +1681,6 @@ /* set socket to non-blocking mode */ set_nonblock (sock->sd); - /* set socket file descriptor to not pass across execs, so that - scripts don't have access to it */ - set_cloexec (sock->sd); - if (socket_defined (sock->ctrl_sd)) set_cloexec (sock->ctrl_sd); -- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] Preparing 2.4-beta1 upload to Debian (Experimental)
Hi, I'm preparing an upload to Debian Experimental of 2.4-beta1 in order to get the maximum exposition as possible. In the meantime I'd like to know your opinion on the following patch that I've been applying to Debian's package for some years: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=367716;filename=openvpn_367716.diff;msg=10 Fixing this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716 Thanks, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] systemd: Improve the systemd unit files
On Tue, Nov 08, 2016 at 09:27:20PM +0100, David Sommerseth wrote:
> On 08/11/16 16:40, debbie10t wrote:
> > Hi,
> >
> > I now have these unit files working on all my test VMS.
> >
> > The only problem before was that on debian 8 these services failed to
> > start after reboot. (systemctl enable openvpn-{client/server}@config
> > was enabled) The error message was:
> > main process exited, code=exited, status=233/RUNTIME_DIRECTORY
>
> It sounds like there's a conflict with a pre-existing directory.
>
> Do you have a chance to check if the stock openvpn version you had
> installed ships with a pre-created /var/run/openvpn directory? (or
> /run/openvpn, or whatever Debian uses as the runtime directory)
>
> Otherwise, great testing!
>
The Debian package creates /run/openvpn/.
/var/run is a symlink to /run in Debian.
--
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com
Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] OpenVPN v2.4 release progress
ut release/2.4 happens here. > >> > >> Reason: We need to ensure people will have at least _some_ time to > >> test before Christmas and some have the ability to run tests > >> during the last weeks of December. > >> > >> > >> * January 4th, 2017 > >> Final release of v2.4.0 > >> > >> > >> The list of patches are the most recent ones I spotted on the mailing > >> list which seems relevant. We might consider other patches too, my > >> patch list is just a proposal. > >> > >> One remark to one the patches: The VRF patches I consider for v2.4 just > >> because this seems very useful and doesn't add a very complicated patch. > >> Considering that 2.4 will live in Debian for a long while, that > >> platform can make most out of this patch as well. In addition, the > >> feature is well isolated from the rest of the code. > >> > >> To manage such a schedule, we really need to ensure patches gets > >> reviewed and ACKed ASAP to be sure things gets included. It will > >> require some efforts from everyone. > >> > >> > >> Any thoughts or comments? > >> > > We should talk with the debian maintainer and ask what we have to do to > > get 2.4.0 into the new debian. Obviously if he/she does not package > > OpenVPN in time we still loose. > > > > Arne > > I already did. I mentioned that on the IRC yesterday evening. No > response from Alberto so far. > Hi there! I'll go for an upload of 2.4-(beta/rc) to Debian unstable in December. Packages take 6 days to move from unstable to testing (aka Stretch), so if we want 2.4 in Stretch it has to be uploaded at the end of December. I can upload fixes later if needed. I don't know if 2.4 addresses building with openssl 1.1 [1], but that would be a plus. Regards, Alberto [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828477 -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] OpenVPN PolarSSL builds?
On Mon, Apr 14, 2014 at 11:42:23AM +0200, Gert Doering wrote: > Hi, > > On Mon, Apr 14, 2014 at 11:29:28AM +0200, Alberto Gonzalez Iniesta wrote: > > There're already packages for PolarSSL in Debian (and thus, in Ubuntu). > > So I don't think there's need to maintain different ones. > > What's Debian's stance on PolarSSL 1.2.x vs. 1.3.x? This is something > that had me worried for a while, as they are plain incompatible - so > if we finally merge Steffan's patch for Polar 1.3.x support to git master, > different OpenVPN versions will require different PolarSSL versions as > well > > openvpn 2.3.x -> needs PolarSSL 1.2.x, will not build or run with 1.3.x > openvpn 2.4.x -> needs PolarSSL 1.3.x, will not build or run with 1.2.x > > (the decision to not-support PolarSSL 1.2.x in parallel to 1.3.x saves > OpenVPN a lot of #ifdefs in our code, but pushes the burden to the > distribution maintainers) I guess the best solution would be to go for 1.3.x support and backport polarssl to Squeeze and Wheezy. I could contact the polarssl maintainer to see how doable that is. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Re: [Openvpn-devel] OpenVPN PolarSSL builds?
On Mon, Apr 14, 2014 at 11:56:43AM +0300, Samuli Seppänen wrote: > > > Hi, > > > > On 04/14/2014 10:28 AM, Gert Doering wrote: > >> On Mon, Apr 14, 2014 at 11:13:24AM +0300, Samuli Seppänen wrote: > >>> Currently all of the binary builds we provide[*] are linked to OpenSSL. > >>> Would having both OpenSSL and PolarSSL builds make sense (e.g. starting > >>> with 2.4)? > >> I think it would be a nice option. We could even start with 2.3.4 with > >> that, at least for windows... (if PolarSSL can be cross-compiled for > >> windows...) > > PolarSSL works just fine on Windows, OpenVPN-NL already ships for > > Windows, using PolarSSL. > > > > I would really like to release 'vanilla' polarssl-builds too. Make it > > easy for people to pick their favourite SSL library. > > > > However, what about PolarSSL itself? For Windows we just put it in the > > installer. But what about the other platforms? It's less commonly > > available in the distro's, and because of the (at least up to now) > > volatile API's, the rather not unlikely that users get version clashes. > > So, options: > > * Just supply openvpn builds, let users deal with polarssl versioning > > themselves > > * Provide PolarSSL packages too (do we already do that for other libs?) > > * Statically compile in PolarSSL (like OpenVPN-NL does) > > > > I think providing PolarSSL packages too is the neatest, but I'm not sure > > on the work involved in maintaining those. Samuli, any thoughts on this? > > > I don't think maintaining the PolarSSL packages would be as much work as > maintaining the OpenVPN packages. The OpenVPN packages need to keep > track of changes in the OS init systems, handle services restarts etc. > The PolarSSL packages would basically just copy some files to directory > and run a few commands. So I guess it would be quite easy to do. That > said, if we start maintaining PolarSSL debs, we might as well do it > upstream in the PolarSSL project instead of within the OpenVPN project. > We could of course publish the PolarSSL packages in our own apt repos to > make using them easier for our users. There're already packages for PolarSSL in Debian (and thus, in Ubuntu). So I don't think there's need to maintain different ones. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Re: [Openvpn-devel] Regarding pkcs11 support in our Debian/Ubuntu packages
On Thu, Apr 10, 2014 at 11:46:09AM +0200, Lisa Minogue wrote: > I would prefer that Samuli patches pkcs11 for Debian/Ubuntu. I am sure > patches for pkcs11 exist for other Linux distros. So why should Debian/Ubuntu > be left out? In addition Ubuntu is the most popular among Linux distros. > > How long does it take for Samuli to issue the pkcs11 patch for Debian/Ubuntu? > One week? Two weeks? One month? We can wait so long as we know that a quality > patch is available at the end of the wait. > > Is it difficult to patch pkcs11 for Debian/Ubuntu compared to patching for > other Linux distros? That could be the reason Samuli decided not to patch for > Debian/Ubuntu. > > It is the OpenSSL "Heartbleed" bug that leads to Samuli being so busy over > the past few days. We appreciate his time and effort spent on rolling out new > versions of OpenVPN software. > Hi Leroy, Mind this patch is only required for Samuli's (backported) packages. The packages in Debian (and later Ubuntu) do not need any patching, since the required version of pkcs11 is already present in the development and testing suites (sid and jessie). Regards, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
[Openvpn-devel] Patch to make uppercasing x509-username-field optional
Hi,
Andris Kalnozols from HP sent me the attached patch in order to make
upper casing the --x509-username-field optional so that fields called
something like "emailAddress" could be used.
He proposed using square brackets [1] in order to specify a field name that
should not be capitalized. Please consider its inclusion, or an
alternative to address this matter.
Thanks,
Alberto
[1]
x509-username-field foo -> will look for a field named FOO
x509-username-field [emailAddress] -> will look for emailAddress
--
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com
Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
--- openvpn-2.3.2/src/openvpn/options.c.orig2013-09-09 01:41:26.0 -0700
+++ openvpn-2.3.2/src/openvpn/options.c 2013-09-09 01:21:30.0 -0700
@@ -6750,8 +6750,23 @@
{
char *s = p[1];
VERIFY_PERMISSION (OPT_P_GENERAL);
- if( strncmp ("ext:",s,4) != 0 )
-while ((*s = toupper(*s)) != '\0') s++; /* Uppercase if necessary */
+ if (strncmp ("ext:", s, 4) != 0)
+ {
+ /* By default, the alphabetic characters of an alternate
+ * username field are uppercased. Accommodate special
+ * requirements, however, by leaving the field name
+ * unchanged if it is enclosed by square brackets.
+ */
+ size_t s_len;
+ s_len = strlen (s);
+ if (*s == '[' && *(s + s_len - 1) == ']')
+ {
+ memmove (s, s + 1, s_len - 2);/* strip the quoting brackets */
+ *(s + s_len - 2) = '\0';
+ }
+ else
+ while ((*s = toupper (*s)) != '\0') s++;
+ }
options->x509_username_field = p[1];
}
#endif /* ENABLE_X509ALTUSERNAME */
Re: [Openvpn-devel] Fix for CVE-2013-2061 breaks multihome?
On Mon, Jun 17, 2013 at 05:36:23PM +0200, Gert Doering wrote: > Hi, > > On Mon, Jun 17, 2013 at 04:36:44PM +0200, Alberto Gonzalez Iniesta wrote: > > Seems like "cmsg_len" went nuts... > > Seems your compiler grew too much smarts and optimized that bug to death :-) > > > Again, only happens with multihome, if that helps... > > That code path is only used for multihome. Bugfix is here (if it's indeed > *that* problem): > Thanks a log Gert. Yes, applying the patch solved the problem. Cheers, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
[Openvpn-devel] Fix for CVE-2013-2061 breaks multihome?
Hi, I applied the fix for CVE-2013-2061 [0] to Debian's stable version of openvpn (2.2.1) [1]. When the new package was sent to the mirrors I got a couple of reports of broken VPNs [2]. After some testing I think the problem arises with the use of "multihome" option. The server daemon starts to log lots of these: Jun 17 12:43:52 srv ovpn-srv[31073]: write UDPv4 []: Invalid argument (code=22) Jun 17 12:43:53 srv ovpn-srv[31073]: write UDPv4 []: Invalid argument (code=22) If the "multihome" option is removed, the VPN comes back to live. Could a patch to fix this be made or should we go back to 2.2.1 without the patch to fix CVE-2013-2061? Thanks, Alberto [0] https://github.com/OpenVPN/openvpn/commit/11d21349a4e7e38a025849479b36ace7c2eec2ee [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707329 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712414 -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Re: [Openvpn-devel] Repos for Debian Wheezy?
Well, 2.3 is in the Debian repos. Both in sid (unstable) and jessie (testing). Wheezy (Stable) was frozen (no more updates) way before OpenVPN 2.3.0 was released, so its inclusion was not possible. We'll have a backport of 2.3.x for wheezy. On Wed, May 29, 2013 at 02:37:12PM -0400, Praetorian wrote: > I'll take a look at the one in unstable. I'm not sure what parts have been > back ported to 2.2 that I have been testing in the 2.3 branch. I would > have thought that 2.3 is mature enough to be in the debian repos by now. > > > On Wed, May 29, 2013 at 9:38 AM, Alberto Gonzalez Iniesta > <a...@inittab.org>wrote: > > > On Wed, May 29, 2013 at 02:29:57PM +0200, Gert Doering wrote: > > > Hi, > > > > > > On Wed, May 29, 2013 at 08:24:43AM -0400, Praetorian wrote: > > > > With the stable release of Wheezy is there a time frame that there > > might be > > > > a openvpn repo for Wheezy? I have a multisite setup that I would like > > to > > > > update to Wheezy that could take advantage of some of the advancements > > in > > > > Wheezy. Sadly ver 2.2 is what is in the Debian repo for Wheezy > > currently. > > > > The setup currently runs off the 2.3 version for some of the ipv6 > > needs. > > > > > > Isn't Debian incorporating the IPv6 patches anyway that bring most of > > > the 2.3 ipv6 functionality to 2.2? > > > > Yes, it is. AFAIK. > > Anyway, I'll try to make a backport one of these days, but the one in > > unstable should work in Wheezy too. > > > > -- > > Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico > > agi@(inittab.org|debian.org)| en GNU/Linux y software libre > > Encrypted mail preferred| http://inittab.com > > > > Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 > > > > > > -- > > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > > Get 100% visibility into your production application - at no cost. > > Code-level diagnostics for performance bottlenecks with <2% overhead > > Download for free and get started troubleshooting in minutes. > > http://p.sf.net/sfu/appdyn_d2d_ap1 > > ___ > > Openvpn-devel mailing list > > Openvpn-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > > -- > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Re: [Openvpn-devel] Repos for Debian Wheezy?
On Wed, May 29, 2013 at 02:29:57PM +0200, Gert Doering wrote: > Hi, > > On Wed, May 29, 2013 at 08:24:43AM -0400, Praetorian wrote: > > With the stable release of Wheezy is there a time frame that there might be > > a openvpn repo for Wheezy? I have a multisite setup that I would like to > > update to Wheezy that could take advantage of some of the advancements in > > Wheezy. Sadly ver 2.2 is what is in the Debian repo for Wheezy currently. > > The setup currently runs off the 2.3 version for some of the ipv6 needs. > > Isn't Debian incorporating the IPv6 patches anyway that bring most of > the 2.3 ipv6 functionality to 2.2? Yes, it is. AFAIK. Anyway, I'll try to make a backport one of these days, but the one in unstable should work in Wheezy too. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
[Openvpn-devel] Using --mlock and --user makes openvpn "run out of memory"
Hi, There's an open bug in Debian [1] since 2007, that seems to be quite documented right now. To sum up, when you run openvpn with --mlock and --user, the daemon will die with "out of memory", possibly due to mlock(2): BUGS Since kernel 2.6.9, if a privileged process calls mlockall(MCL_FUTURE) and later drops privileges (loses the CAP_IPC_LOCK capability by, for example, setting its effective UID to a nonzero value), then subsequent memory allocations (e.g., mmap(2), brk(2)) will fail if the RLIMIT_MEMLOCK resource limit is encountered. The bug report contains a workaround (editing PAM limits) and a plea to document this behaviour. I guess it's better to document this (after verification of the facts) in OpenVPN's man page rather than just Debian's package. Regards, Alberto [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406895 -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?
On Fri, Mar 16, 2012 at 02:09:44PM +0200, Alon Bar-Lev wrote: > On Fri, Mar 16, 2012 at 1:47 PM, Alberto Gonzalez Iniesta > <a...@inittab.org> wrote: > > Since support for LZO is enabled/disabled in runtime configuration, I > > don't see why disabling it on built time, thus limiting its use later. > > We are talking about the build. I know. > Runtime is irrelevant. Sure. Specially after you build a package that no longer supports a feature present before. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] New generic buildsystem: lzo enabled or disabled by default?
On Fri, Mar 16, 2012 at 01:38:47PM +0200, Samuli Seppänen wrote: > Hi all, > > In yesterday's meeting we reviewed this patch > > PATCH 39/52 build: proper lzo detection and usage > URL: http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5811 > > The patch was ACKed, but there was disagreement whether LZO should be enabled > or disabled by default. Whichever the case, it will only affect people > building OpenVPN, not the end-users. Official builds will continue to have > LZO support. > > Opinions? > I'll still build Debian packages with LZO support (if I don't forget to set the option when upgrading to the new version). Since support for LZO is enabled/disabled in runtime configuration, I don't see why disabling it on built time, thus limiting its use later. Regards, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] Errors adding routes on Windows 7 with OpenVPN 2.1.3
On Thu, Oct 21, 2010 at 10:38:52AM +0200, Gert Doering wrote: > Hi, > > On Wed, Oct 20, 2010 at 09:31:35PM +0200, Gert Doering wrote: > > I think the patch below should fix this, but have not tested this at all > > (neither with nor without the patch). Applies to tag v2.1.3 > > David suggested to use CLEAR() to make easier-understandable code and > more thorough clearing. Patch (goes on top of the last patch) below. > > Agi, either patch should work, but if you haven't tested the other one > yet, please test this one. > Hi, I tested the patch successfully. It works for me(tm). OpenVPN stopped adding those random routes, while it added the right one for the "remote_host". Thanks, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] Errors adding routes on Windows 7 with OpenVPN 2.1.3
On Mon, Oct 18, 2010 at 05:50:44PM +0200, Christian Rank wrote: > Hello, > > we noticed a strange problem with OpenVPN 2.1.3 on a Windows 7 client > here: The VPN tunnel to an OpenVPN server does no longer work since the > OpenVPN 2.1.3 software tries to insert many strange routes into the > Windows 7 routing tables. With OpenVPN 2.1.1, all goes well. Our OpenVPN > server is running on OpenVPN 2.1_rc15 i686-pc-linux-gnu. > > I have attached the Windows OpenVPN log file (with verbosity 4). > > Maybe this is a bug in the Windows implementation of OpenVPN 2.1.3? > Hi Christian, It's not a bug in the Windows implementation but in OpenVPN 2.1.3 itself. The bug is reported and it is being worked in. I think you're using 'remote_host' on your client configuration (or pushing it from the server). If that's the case, try changing that with the IP of the VPN server and see if that fixes it in the meantime. Cheers, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] [PATCH] Fixed typo in manpage
Just a tiny fix. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 Index: openvpn-2.1.0/openvpn.8 === --- openvpn-2.1.0.orig/openvpn.8 2010-04-10 17:07:57.256694284 +0200 +++ openvpn-2.1.0/openvpn.8 2010-04-10 17:08:06.036696780 +0200 @@ -916,7 +916,7 @@ otherwise 0. The default can be specified by leaving an option blank or setting -it to "default". +it to "nil". The .B network
Re: [Openvpn-devel] FQDN for routes should expand to all IPs
On Sat, Oct 24, 2009 at 01:45:04PM -0600, James Yonan wrote: > Stefan Monnier wrote: > > I've posted a bug report at: > > > > http://sourceforge.net/tracker/index.php?func=detail=2872760_id=48978=454719 > > > > since since I haven't heard any reaction for almost 2 weeks now > > (although the report includes a patch which works well, at least for > > me), I'm wondering whether it was the right place. Should I send my > > patches here instead? > > This is the right place to submit bug reports. > > Having said that, your bug report seems more like a feature request > since routing commands/APIs generally do not support DNS A-record > expansion as a standard feature. > > It's an interesting idea though, and one that makes sense, but I haven't > seen any other requests for it. Hi James, Just for the record, the same feature was requested in Debian [1] some 5 years ago :) Regards, Alberto [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237251 -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] remote* enviroment variables wrongly set?
Hi, A user mailed me (he was using the Debian package) pointing out that the remote environment variables weren't set right (remote_X) If the 'local' option is specified, the remote_1 variable will be set to its (local) value. I think the patch attached solves it. Regards, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 Index: openvpn-2.1_rc15/options.c === --- openvpn-2.1_rc15.orig/options.c 2009-04-30 12:58:46.952616319 +0200 +++ openvpn-2.1_rc15/options.c 2009-04-30 12:58:50.352666598 +0200 @@ -769,8 +769,8 @@ setenv_str_i (es, "proto", proto2ascii (e->proto, false), i); setenv_str_i (es, "local", e->local, i); setenv_int_i (es, "local_port", e->local_port, i); - setenv_str_i (es, "remote", e->local, i); - setenv_int_i (es, "remote_port", e->local_port, i); + setenv_str_i (es, "remote", e->remote, i); + setenv_int_i (es, "remote_port", e->remote_port, i); #ifdef ENABLE_HTTP_PROXY if (e->http_proxy_options)
[Openvpn-devel] rc9 and external commands
Hi James,
It seems that tightening the security on OpenVPN brought some surprises
[1] to users and broke some features [2].
As for [1], I included a note in the Debian NEWS file on the new
--script-security option. But those updating a VPN using the very same
VPN (and without previous knowledge of this option) may find themselves
without access to the remote system (if the VPN/system is restarted, and
a script is to be executed). Also, those using NetworkManager [3] aren't
able to specify the '--script-security' option, and since NetworkManager
may/will call external scripts, this new security feature will break
their VPNs. The option is really useful, but 2 would be a more sensible
default IMHO.
Regarding [2] an strace shows that calls to external commands with
arguments include the arguments as part of the command filename:
For:
--up "/tmp/foo up"
The call is:
[pid 3519] execve("/tmp/foo up", ["/tmp/foo up", "tun0", "1500", "1542",
"10.XXX.XXX.X", "10.XXX.XXX.X", "init"], [/* 30 vars */]) = -1 ENOENT
(No such file or directory)
Where in previous versions the call was:
[pid 4074] execve("/tmp/kk", ["/tmp/kk", "up", "tun0", "1500", "1542",
"10.XXX.XXX.X", "10.XXX.XXX.X", "init"], [/* 51 vars */]) = 0
Please let me know what's your opinion regarding [1].
Thanks a lot,
Alberto
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494998
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495964
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494998#10
--
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com
Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] Re: Fwd: openvpn config parsing
On Wed, Dec 22, 2004 at 05:11:51AM -0700, James Yonan wrote: > On Wed, 22 Dec 2004, Charles Duffy wrote: > > > On Wed, 22 Dec 2004 11:00:09 +0100, Alberto Gonzalez Iniesta wrote: > > > Recent updates of openvpn appear to have changed the handling of > > > whitespace in tls certificate names. > > ... > > > Now it needs '_' not '.' for spaces: > > > > My guess is that this is a consequence of some string-handling changes > > that were going on around 2.0-beta12 to 2.0-beta15. > > Yes, this is something that needs to be better documented. Prior to > 2.0-beta12, the string remapping code was a bit ad-hoc. Since then I've > tried to unify all string remapping towards a consistent model which > remaps illegal chars to '_'. The choice of underbar is arbitrary -- any > inert character will do. Thanks Charles & James, I'll document this in the Debian package README file. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.org Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] Fwd: openvpn config parsing
Hi, yet another report on feature changes not documented. I thought this may be related to --key-method 2 only, but it seems to be the same on --key-method 1. Has this changed some where in the 2.x development? In that case, we should document this for old users. Thanks. - Forwarded message from Ron <r...@debian.org> - From: Ron <r...@debian.org> To: Alberto Gonzalez Iniesta <a...@inittab.org> Subject: openvpn config parsing List-Post: openvpn-devel@lists.sourceforge.net Date: Fri, 10 Dec 2004 12:09:42 +1030 X-CRM114-Version: 20040816.BlameClockworkOrange-auto.3 (regex: TRE 0.6.8) MF-A10FFB4C X-CRM114-Status: Good ( pR: 0.9831 ) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Level: Hi Alberto, Recent updates of openvpn appear to have changed the handling of whitespace in tls certificate names. ie. for: Subject: C=Oz, ST=Secured, L=Zone, O=Riviera tunnel, OU=uoa VPN client, CN=twain.riviera.oz/emailAddress=keymaster@oz I used to need: tls-remote /C=Oz/ST=Secured/L=Zone/O=Riviera.tunnel/OU=uoa.VPN.client/CN=twain.riviera.oz/emailAddress=keymaster@oz Now it needs '_' not '.' for spaces: tls-remote /C=Oz/ST=Secured/L=Zone/O=Riviera_tunnel/OU=uoa_VPN_client/CN=twain.riviera.oz/emailAddress=keymaster@oz This might be worth a mention in the readme, it broke my existing setup 'silently' -- though it might have been easier to find if I didn't run off chasing red herrings based on prior upgrade breakages first :-) Anyway, thanks for maintaining this one, speaking as an old time user of cipe, this really is a very nice 'next step' in that problem space. best, Ron - End forwarded message - -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.org Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] When the link used for openvpn goes down, the daemon hangs
On Wed, Nov 03, 2004 at 12:24:15PM -0700, James Yonan wrote: > On Tue, 2 Nov 2004, Alberto Gonzalez Iniesta wrote: > > > Hi again, > > > > Another bug report received in the Debian BTS [1]. Quoting: > > |when the link which was used for openvpn transport goes down, it hangs > > |in a D state > > | > > |root 2037 0.0 0.2 3376 1620 pts/1D10:45 0:04 openvpn > > | > > |and there is no way to kill it, I have to reboot. Other programs (eg. > > |wavemon) can handle this situation more sanely. > > Any idea how to reproduce it? > > OpenVPN normally has no problem with intermittent links. No idea, James. I wasn't able to reproduce it. I can unplug the ethernet cable, ifconfig ethX down, but OpenVPN will not hang and it will recover once the cable is back or the interface is up. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.org Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] When the link used for openvpn goes down, the daemon hangs
Hi again, Another bug report received in the Debian BTS [1]. Quoting: |when the link which was used for openvpn transport goes down, it hangs |in a D state | |root 2037 0.0 0.2 3376 1620 pts/1D10:45 0:04 openvpn | |and there is no way to kill it, I have to reboot. Other programs (eg. |wavemon) can handle this situation more sanely. Regards, Alberto [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278933 -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.org Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] OpenVPN 2.0 and udev
On Sun, Oct 17, 2004 at 01:36:33PM -, James Yonan wrote: > Alberto Gonzalez Iniesta <a...@inittab.org> said: > > > Hi all, > > > > After I decided to push OpenVPN 2.0 into Debian for future inclusion in > > Sarge, I got this [1] bug report from one Debian user. It seems that 2.0 > > doesn't get along well with udev, as opposed to 1.6. I don't use udev, > > so I can't really tell, but has anything changed from 1.6 to 2.0 in the > > way the device is handled? > > > > The suspicious message is: > > > > Oct 16 16:31:12 gimli wait_for_sysfs[5873]: error: wait_for_sysfs needs an > update to handle the device '/class/net/tun0' properly, please report to > <linux-hotplug-de...@lists.sourceforge.net> > > > > The bug submitter claims that OpenVPN 1.6 deals correctly with it. Maybe > > it has something to do with device probing? > > The TUN/TAP handling code in 2.0 is nearly identical to the 1.6 code. The > only change I can think of is the setting of txqueuelen on the TUN/TAP driver. Ok > Incidentally, the error shown in the bug report looks like he is trying to > make a tunnel between 1.6 and 2.0 using incompatible key-method parameters. > He needs to set --key-method 2 on the 1.6 side. Has this changed between 1.6 and 2 beta11? The man page says --key-method defaults to 1 and the ChangeLog does not say otherwise. I don't think this guy changed that to 2 just after he upgraded the package. I'll ask him anyway, yo never know... Could a problem with the TUN/TAP driver confuse the --key-method handling code? > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276799 > > > > > > P.S. James, did you find out anything about this [2]? Do you think it > > could be due to hardware (RAM) problem? I'm thinking about tagging it > > irreproducible. > > Yes, I would tend to mark it as irreproducible for now. I tried to contact > him for more info, but haven't received any response. Ok, thanks a lot. I'll tag it 'unreproducible' and 'moreinfo' so 'the ball will be on his side'. :) -- Alberto Gonzalez Iniesta| BOFH excuse #47: agi@(inittab.org|debian.org)| Complete Transient Lockout Encrypted mail preferred| Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] OpenVPN 2.0 and udev
Hi all, After I decided to push OpenVPN 2.0 into Debian for future inclusion in Sarge, I got this [1] bug report from one Debian user. It seems that 2.0 doesn't get along well with udev, as opposed to 1.6. I don't use udev, so I can't really tell, but has anything changed from 1.6 to 2.0 in the way the device is handled? The suspicious message is: Oct 16 16:31:12 gimli wait_for_sysfs[5873]: error: wait_for_sysfs needs an update to handle the device '/class/net/tun0' properly, please report to <linux-hotplug-de...@lists.sourceforge.net> The bug submitter claims that OpenVPN 1.6 deals correctly with it. Maybe it has something to do with device probing? Thanks, Alberto [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276799 P.S. James, did you find out anything about this [2]? Do you think it could be due to hardware (RAM) problem? I'm thinking about tagging it irreproducible. [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265632 -- Alberto Gonzalez Iniesta| BOFH excuse #175: agi@(inittab.org|debian.org)| OS swapped to disk Encrypted mail preferred| Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] Assertion failed at crypto.c:147
Hi all, After returning from my holidays, I found the following two [1][2] bug reports in the Debian Bug Tracking System. I haven't had this problem and the source code says it should never happen :) so any hints would be appreciated. Thanks, Alberto http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265632 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270005 -- Alberto Gonzalez Iniesta | BOFH excuse #178: agi@(agi.as|debian.org)| short leg on process table Encrypted mail preferred | Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] route option deleting routes it didn't set
Hi, We got a bug report at Debian [1] regarding the route option. It turns out that if a route added by openvpn is later modified (removed and added to other iface), openvpn will modify (delete) the later one. As the bug submitter states, maybe openvpn should specify the device it wants the route deleted from. [1] http://bugs.debian.org/251304 -- Alberto Gonzalez Iniesta | BOFH excuse #263: agi@(agi.as|debian.org)| It's stuck in the Web. Encrypted mail preferred | Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] OpenVPN 2.0 -- Project Update and Release Notes
On Wed, Mar 31, 2004 at 12:31:13PM +0200, Alberto Gonzalez Iniesta wrote: > Debian package available (for testing/unstable) at: > > http://tmp.inittab.org/~agi/openvpn_2.0_beta18-1_i386.deb > Sorry, that should read: http://tmp.inittab.org/~agi/openvpn_2.0_test18-1_i386.deb It's a test release, not a beta one. -- Alberto Gonzalez Iniesta | BOFH excuse #367: agi@(agi.as|debian.org)| Webmasters kidnapped by evil cult. Encrypted mail preferred | Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] OpenVPN 2.0 -- Project Update and Release Notes
On Tue, Mar 30, 2004 at 11:15:45PM -, James Yonan wrote: > OpenVPN 2.0 -- Project Update and Release Notes > > I'm happy to announce that the first OpenVPN 2.0 beta is here, and well ahead > of schedule. This is in large part thanks to a generous contribution by > Meetrix Inc. which has allowed me to work full-time on the project during the > last month. Wow! Impressive job James! Thanks a lot for your work. And thanks Meetrix for your support! Debian package available (for testing/unstable) at: http://tmp.inittab.org/~agi/openvpn_2.0_beta18-1_i386.deb Consider it Beta, and report bugs to openvpn-devel@lists.sourceforge.net (in case of openvpn related problem) or me (in case of packaging errors). -- Alberto Gonzalez Iniesta | BOFH excuse #191: agi@(agi.as|debian.org)| Just type 'mv * /dev/null'. Encrypted mail preferred | Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 signature.asc Description: Digital signature
[Openvpn-devel] route option only adds route for first IP resolved for a hostname (with many)
Hi James et all, I have just got this bug report [1]. The problem is: When a hostname is given to the 'route' option, only a route to the first IP address for that hostname is added. route(8) works the same way, and I don't know if this is really a bug, or The Way is Meant to Be (tm) Any thoughts? [1] http://bugs.debian.org/237251 -- Alberto Gonzalez Iniesta | BOFH excuse #304: agi@(agi.as|debian.org)| routing problems on the neural net Encrypted mail preferred | Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] Fwd: Bug#182020: openvpn needs dynamic choice on HAVE_LINUX_IF_TUN_H
On Thu, May 08, 2003 at 08:30:34AM -, James Yonan wrote: > Alberto Gonzalez Iniesta <a...@agi.as> said: > > > When compiled with 2.4.* kernel headers (libc6-dev 2.2.5-14.3 headers) > > it detects this header file and defines HAVE_LINUX_IF_TUN_H. This allow > > openvpn to work correctly with 2.4.18 kernels BUT it stops it working > > with 2.2.X kernels at all (with or without the tun kernel module from > > sourceforge) > > OpenVPN's config script assumes that if 2.4 headers are present (i.e. > if_tun.h), then it should build for the 2.4 tun/tap driver. > > I don't completely understand why one would want to put 2.4 kernel headers on > a 2.2 machine, since that would tend to confuse things, and break apps that > depend on the userspace <-> kernel interface as defined by the kernel header > files. The problem (again) is distributing binaries. I compile Debian's packages in my 2.4.x box, but those packages may be used in 2.2 boxes. I could find a 2.2 box (could I?) to compile them, but then the problem would be the other way around, wouldn't it? So, and as the bug reported says, we have two choices: a) I make two binaries in the package, and choose at installation time which one should be used. (will uname -r do? I guess so) b) openvpn detects at run time which tun interface to use. pros? cons? Regards, Alberto > But in any case, you can still build if you do the following. > > (1) run ./configure > (2) edit config.h > (3) comment out this line: #define HAVE_LINUX_IF_TUN_H 1 > (4) run make > > This could be automatic if ./configure did a kernel version test, and only > defined HAVE_LINUX_IF_TUN_H if (a) if_tun.h exists and (b) kernel version is > 2.4.x. > > James > > > Options are: > > > > 1) Seperate compiles for 2.2.X and 2.4+ kernels, both binaries in the .deb > > > > 2) Patch tun.c to first check if /dev/net/tun exists and works before > >falling back to the open_tun_generic(..) function if it doesn't. > > > > I'm currently successfully using openvpn between a 2.2.19 and 2.4.18 > > kernel using the tun0 tunnel and the driver from sourceforge on the 2.2.19 > > machine. (No reboot required to install the tun0 driver) The 2.4.18 > > openvpn is standard, the 2.2.19 has HAVE_LINUX_IF_TUN_H undefined. > > > > Both machines are woody with libc6/testing. > > -- Alberto Gonzalez Iniesta | BOFH excuse #99: agi@(agi.as|debian.org)| SIMM crosstalk. Encrypted mail preferred | Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] Fwd: Re: Compiling and/or linking liblzo with OpenSSL
Here's my last email with Markus about this subject. I'm forwarding it as he requested. Maybe we should quote his exception somewhere in the tarball, James? - Forwarded message from "Markus F.X.J. Oberhumer" <mar...@oberhumer.com> - From: "Markus F.X.J. Oberhumer" <mar...@oberhumer.com> To: Alberto Gonzalez Iniesta <a...@agi.as> Subject: Re: Compiling and/or linking liblzo with OpenSSL List-Post: openvpn-devel@lists.sourceforge.net Date: Sat, 3 May 2003 16:57:42 +0200 X-no-Archive: yes X-GPG-KeyID: 0x0B2043C9 X-GPG-Fingerprint: 1077 CF79 F341 3A50 03A3 93CE 4D61 57AB 0B20 43C9 X-GPG-Keyserver: http://www.keyserver.net/ X-Oberhumer-Conspiracy: There is no conspiracy. At least not today. X-SpamProbe: GOOD 0.000 885e45b1c2c5ae91fe5eefa0772b2336 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Hello Alberto, thanks for all the info - I was not aware that OpenSSL uses the old style BSD license (and that all the problems just arise from the advertising clause). On Sat, 3 May 2003 11:51:42 +0200 Alberto Gonzalez Iniesta wrote: > First of all, thanks for your support. And sorry for any inconvenience. > That exception should be enough for us. > May I quote it in Debian's package? Sure, it the paragraph below is fine for you (I hope there are no more typos left...) then please add that. Also please forward this mail to the upstream OpenVPN developer. Regards, Markus Hereby I grant a special exception to the OpenVPN project (http://openvpn.sourceforge.net) to link the LZO library with the OpenSSL library (http://www.openssl.org). Markus F.X.J. Oberhumer -- Markus Oberhumer, <mar...@oberhumer.com>, http://www.oberhumer.com/ ----- End forwarded message - -- Alberto Gonzalez Iniesta | agi@(agi.as|debian.org)| Encrypted mail preferred | Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] Fwd: Re: comp-lzo and licensing issues
On Fri, May 02, 2003 at 06:07:07PM +0200, Matthias Andree wrote: > On Mon, 28 Apr 2003, Alberto Gonzalez Iniesta wrote: > > > Sorry for the huge forward, but everything needed to understand this > > problem should be there :) > > FYI: > > My post of the FreeBSD-ports mailing list how I should handle this > license issue LZO <-> OpenSSL hasn't turned up anything in some days; so > no-one has an opinion there... > > I'll forbid packaging binaries when I update the port for OpenVPN 1.4.0, > just to be sure. OpenSSL is in the base system of FreeBSD, so I don't > consider this urgent, but it should be fixed eventually. If OpenSSL is in the base system of FreeBSD, then there shouldn't be any problem linking LZO with it. You could also allow OpenVPN binaries without LZO support (as I currently do in Debian). Anyway, Markus got in contact with me (I'll forward his message next to this one) and we have permission to use LZO with OpenSSL in OpenVPN :) So,... End Of Thread (for the time being?) -- Alberto Gonzalez Iniesta | They that give up essential liberty agi@(agi.as|debian.org)| to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. -- Benjamin Franklin Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] Fwd: Re: comp-lzo and licensing issues
Hi all, Sorry for the huge forward, but everything needed to understand this problem should be there :) GPL software does not mix well with OpenSSL, and that's giving me some headaches lately. As you me see in my mail to Markus (liblzo author) and James (we all know who he is :) linking liblzo with OpenSSL may be a GPL violation [1]. So this is a call for comments on this issue. Can anybody reach Markus and comment him about this? Should we switch to another compression library? In that case, which one would be suitable? zlib? Should we ignore this and let RMS jump on us? [2] Hoping to get lots of feedback, Alberto [1] http://www.openssl.org/support/faq.html#LEGAL2 [2] Yes, it's a joke - Forwarded message from James Yonan <j...@yonan.net> - From: James Yonan <j...@yonan.net> To: Alberto Gonzalez Iniesta <a...@agi.as> Subject: Re: comp-lzo and licensing issues List-Post: openvpn-devel@lists.sourceforge.net Date: Sat, 26 Apr 2003 16:57:26 - X-SpamProbe: GOOD 0.000 6c2c0cd892c1100831080d47b6f1d8e2 Hi Alberto, How are you doing? I haven't heard from you for a while! Interesting problem. Well I hope that Markus will agree to the linkage. It seems that this must be a common problem, if GPL cannot co-exist with licenses which are still open source but non-GPL. It also seems that the whole notion of "linkage" is a thorny issue and would need to be rigorously defined. For example, does gpl-program | non-gpl-program > conundrum.log constitute linkage? What if the linkage is between components in user space and kernel space that have different licenses, but otherwise comingle in the same address space? Is linkage via shared libraries or static linkage different from interprocess communication linkages or network communication linkages? As you mention, zlib is certainly another option, though I don't know how it scores in the realtime category. It would also need to be able to compress/decompress small blocks (i.e. MTU sized) without reference to other blocks or cross-block state-info. I would agree that you should post something to openvpn-devel about this. Best Regards, James Alberto Gonzalez Iniesta <a...@agi.as> said: > > --/WwmFnJnmDyWGHa4 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Hi James, > > First of all, sorry for the delay in contacting you about this. :( > I'm mailing you off the list because this is can be picky subject. You > may take this subject to the list whenever you feel like. > > As you can see in http://bugs.debian.org/177497 , I had to disable > liblzo support in Debian's packages due to a (possible) GPL violation. > > Remember the exception you did to OpenVPN's license so it could be built > against OpenSSL? Well, the same thing should be done with liblzo. I > mailed liblzo's author on Jan 26, but I got no answer from him. (See > attachment) > > So, what happens now? From my point of view, we have two choices: > a) Try (again) to convince LZO's author to make the exception in his > source. Until that happens I won't be able to package OpenVPN with LZO > support (and lots of people require it. See bugs.d.o/182549 and 187117) > > b) My No 1 wishlist request for OpenVPN: a new compression library. > For example: zlib, which uses a BSD like license and it's used in > OpenSSH. > > Please, let me know what you think of all this. And, of course, feel > free to take this discussion to the -devel list. > > Thanks, > > Alberto > > --=20 > Alberto Gonzalez Iniesta | They that give up essential liberty > agi@(agi.as|debian.org)| to obtain a little temporary safety > Encrypted mail preferred | deserve neither liberty nor safety. > > Key fingerprint =3D 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 > > --/WwmFnJnmDyWGHa4 > Content-Type: message/rfc822 > Content-Disposition: inline > > Date: Sun, 26 Jan 2003 10:51:01 +0100 > From: Alberto Gonzalez Iniesta <a...@agi.as> > To: Markus Franz Xaver Johannes Oberhumer <markus.oberhu...@jk.uni-linz.ac.at> > Subject: Compiling and/or linking liblzo with OpenSSL > Message-ID: <20030126095100.ga2...@var.inittab.org> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > User-Agent: Mutt/1.5.3i > > Hi Markus, > > I'm the Debian Maintainer of OpenVPN (http://openvpn.sourceforge.net). > OpenVPN is, as you may guess, a VPN software with liblzo support for > improved performance. It's GPL'ed just like liblzo, but uses OpenSSL. > > It seems that GPL and OpenSSL don't mix well: > http://www.openssl.org/support/faq.html#LEGAL2 > > Since we're *very* picky with licenses in Debian, I had to disable libzo > supp
Re: [Openvpn-devel] Fwd: RE: Multi-channel VPN
On Fri, Apr 18, 2003 at 05:53:07AM -, James Yonan wrote: > I'm forwarding this discussion of an interesting feature request. Namely, > could (and should) OpenVPN have a channel bonding capability, where more than > one UDP connection over different paths is used to connect two peers, and > OpenVPN does channel bonding, load balancing, and failover among the > connections? Or does this function not belong in OpenVPN since it is > functionally distinct from the role of network security and tunneling and > could be implemented as a module or driver apart from OpenVPN? > Hi all, IMHO this feature would be out of OpenVPN's scope, just as QoS or firewalling are. It'd add (talking from my ignorant-and-no-developer point of view) lots of complexity, and we know complexity and bugs travel in the same ship :) This can be achieved in both Linux and FreeBSD, it's not easy but it's possible. Let each tool do its job, and only that. -- Alberto Gonzalez Iniesta | They that give up essential liberty agi@(agi.as|debian.org)| to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] Opened file descriptors in script calls
On Sun, Feb 09, 2003 at 08:01:12PM -0500, Aaron Sethman wrote:
>
> Here is a simple little replacement for system() that does close file
> descriptors. The main issue with it is though, it ends up picking an
> arbitrary number of fds to close. I picked closing 0 to 99.
>
> Aaron
>
>
> int s_system(const char *string)
> {
> pid_t pid;
> int x;
> pid = fork()
>
> if(pid == -1)
> {
> return -1;
> }
>
> if(pid > 0)
> {
> int status;
> wait();
> return(status);
> }
>
> for(x = 0; x < 100; x++)
> {
> close(x);
> }
> execlp("/bin/sh", "-c", string);
>
> }
>
Hi,
Again, I'm no C hacker, but I think this should be better:
for(x = 3; x < 100; x++)
Since the first 3 fds (stdin, stdout and stderr) should be kept open.
Regards,
Alberto
--
Alberto Gonzalez Iniesta | They that give up essential liberty
agi@(agi.as|debian.org)| to obtain a little temporary safety
Encrypted mail preferred | deserve neither liberty nor safety.
Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] Opened file descriptors in script calls
Hi, I got another bug report on Debian's openvpn package. It states that openvpn's file descriptors are kept open while scripts are called. It claims they should be closed. My C knowledge is far from make a patch for this one :) And maybe you don't agree with this (James?). You can see the report here: http://bugs.debian.org/179551 Thanks. -- Alberto Gonzalez Iniesta | They that give up essential liberty agi@(agi.as|debian.org)| to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] Trimmed down permissions for generated keys
Hi James et al! Intro - openvpn creates pre-shared secret files, for latter use in static key encryption mode (non-TLS), with the --genkey option The minor/anecdotal glitch -- The permissions for the created file may be/seem to be excessive (0700) Pointed out by Herbert Xu <herb...@gondor.apana.org.au> [1] The patch - --- openvpn-1.3.2.orig/crypto.c +++ openvpn-1.3.2/crypto.c @@ -968,7 +968,7 @@ struct buffer out = alloc_buf_gc (512); /* open key file */ - fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRWXU); + fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRUSR | S_IWUSR); if (fd == -1) msg (M_ERR, "Cannot open shared secret file %s for write", filename); Let me know if you like it/agree, James. Thanks, Alberto [1] http://bugs.debian.org/178849 (PS. I resent this mail, since I first sent it from the wrong address, sorry James) -- Alberto Gonzalez Iniesta | They that give up essential liberty agi@(agi.as|debian.org)| to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] Features comments/request
On Tue, Jun 25, 2002 at 10:02:18AM -0600, James Yonan wrote: > Hi Alberto, > > > I'd like to ask for a couple of features (little ones) added to OpenVPN. > > Comments welcomed. > > > > 1) OpenVPN should refuse to start a connection based on shared secret > > when the file containing that key is world readable (or writable). > > Paranoia won't even like group readable :-) > Good idea, however what if someone doesn't want to deal with the protections > on every file and instead just eliminates group/world access to the key > directory? Therefore, erring on the individual file protections could > create a false sense of paranoia? Hi James, Yes, forcing directory security could be a better solution, but what happens if the user wants to keep the key in a directory like /etc? or /usr/local/etc? From my point of view (Debian's package) there's no problem, I'll probably go for a /etc/openvpn/secrets directory, but just wanted to note this in case you wanted to think about it. > > 2) Each OpenVPN daemon should delete its pidfile when stoping, since it > > was that very same daemon that created it. > > It has no sense to have the init.d scripts deleting these files (and > > stoping nonexistent daemons) since the daemon could have been killed > > before the init.d script tried to stop it. > > The complication here is that a lot of people will want to downgrade > privilege using --user and/or --group. That means that when an OpenVPN > daemon is ready to exit, it might lack the privilege to delete its own > pidfile. I've seen other daemons deal with this by chowning the pid file to > the user/group that the daemon plans to setuid/setgid to. Didn't think of that. Good point. :-) Thanks for your work. Best regards, Alberto -- Alberto Gonzalez Iniesta | They that give up essential liberty a...@agi.as | to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Re: [Openvpn-devel] Features comments/request
On Tue, Jun 25, 2002 at 10:02:18AM -0600, James Yonan wrote: > Hi Alberto, > > > I'd like to ask for a couple of features (little ones) added to OpenVPN. > > Comments welcomed. > > > > 1) OpenVPN should refuse to start a connection based on shared secret > > when the file containing that key is world readable (or writable). > > Paranoia won't even like group readable :-) > Good idea, however what if someone doesn't want to deal with the protections > on every file and instead just eliminates group/world access to the key > directory? Therefore, erring on the individual file protections could > create a false sense of paranoia? Hi James, Yes, forcing directory security could be a better solution, but what happens if the user wants to keep the key in a directory like /etc? or /usr/local/etc? From my point of view (Debian's package) there's no problem, I'll probably go for a /etc/openvpn/secrets directory, but just wanted to note this in case you wanted to think about it. > > 2) Each OpenVPN daemon should delete its pidfile when stoping, since it > > was that very same daemon that created it. > > It has no sense to have the init.d scripts deleting these files (and > > stoping nonexistent daemons) since the daemon could have been killed > > before the init.d script tried to stop it. > > The complication here is that a lot of people will want to downgrade > privilege using --user and/or --group. That means that when an OpenVPN > daemon is ready to exit, it might lack the privilege to delete its own > pidfile. I've seen other daemons deal with this by chowning the pid file to > the user/group that the daemon plans to setuid/setgid to. Didn't think of that. Good point. :-) Thanks for your work. Best regards, Alberto -- Alberto Gonzalez Iniesta | They that give up essential liberty a...@agi.as | to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] Features comments/request
Hi all, James, I'd like to ask for a couple of features (little ones) added to OpenVPN. Comments welcomed. 1) OpenVPN should refuse to start a connection based on shared secret when the file containing that key is world readable (or writable). Paranoia won't even like group readable :-) Really, that's an important piece (the most?) in that kind of VPN, we don't want it to be public. Just imagine an (non-chrooted) anonymous ftp server, a bad configured web server/cgi-script, a malicious user,... 2) Each OpenVPN daemon should delete its pidfile when stoping, since it was that very same daemon that created it. It has no sense to have the init.d scripts deleting these files (and stoping nonexistent daemons) since the daemon could have been killed before the init.d script tried to stop it. Thanks in advance for any comments. Best regards. -- Alberto Gonzalez Iniesta | They that give up essential liberty a...@agi.as | to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
[Openvpn-devel] Features comments/request
Hi all, James, I'd like to ask for a couple of features (little ones) added to OpenVPN. Comments welcomed. 1) OpenVPN should refuse to start a connection based on shared secret when the file containing that key is world readable (or writable). Paranoia won't even like group readable :-) Really, that's an important piece (the most?) in that kind of VPN, we don't want it to be public. Just imagine an (non-chrooted) anonymous ftp server, a bad configured web server/cgi-script, a malicious user,... 2) Each OpenVPN daemon should delete its pidfile when stoping, since it was that very same daemon that created it. It has no sense to have the init.d scripts deleting these files (and stoping nonexistent daemons) since the daemon could have been killed before the init.d script tried to stop it. Thanks in advance for any comments. Best regards. -- Alberto Gonzalez Iniesta | They that give up essential liberty a...@agi.as | to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
