Re: [Openvpn-devel] Windows installer with updated pkcs11-helper (1.22) available for testing

On Wed, 2017-07-26 at 11:16 +0200, David Sommerseth wrote: > On 26/07/17 10:02, David Woodhouse wrote: > [...snip...] > > > > > > Well yes, that's true. But it's more likely that I'll finally get round > > to porting OpenVPN to something other than pkcs11-

Re: [Openvpn-devel] Windows installer with updated pkcs11-helper (1.22) available for testing

On Tue, 2017-07-25 at 23:56 +0200, Emmanuel Deloget wrote: > A single patch would not a a problem for distro maintainers, but > subsequent/future changes in the forked repository might introduce > other, less compatible changes in the library, leading to two versions > of the same library, with

Re: [Openvpn-devel] Windows installer with updated pkcs11-helper (1.22) available for testing

On Tue, 2017-07-25 at 19:53 +0300, Samuli Seppänen wrote: > > I released the new Windows installer but without this patch. That said, > the patch/PR you linked to makes sense. Does the patch have an active > maintainer? That would be me, I suppose. Until/unless the upstream maintainer applies

Re: [Openvpn-devel] Windows installer with updated pkcs11-helper (1.22) available for testing

On Fri, 2017-07-14 at 17:07 +0300, Samuli Seppänen wrote: > Hi all, > > Those of you who use pkcs11 on Windows: could you please test this new > Windows installer: > > > > The previous installer(s) had pkcs11-helper 1.11. This one has 1.22, so > some regression testing would be good to have.

Re: [Openvpn-devel] [PATCH 0/2] LZ4 updates

On Thu, 2016-12-15 at 21:20 +0100, David Sommerseth wrote: > > There is also another potential issue with the current approach, if we link > against r129 or older ... the code will be using > LZ4_compress_limitedOutput().  If the system library is upgraded to a newer > upstream version which

Re: [Openvpn-devel] [PATCH 1/1] replace deprecated LZ4 function

On Thu, 2016-12-15 at 14:26 +0100, Christian Hesse wrote: > -    zlen = LZ4_compress_limitedOutput((const char *)BPTR(buf), (char > *)BPTR(work), BLEN(buf), zlen_max ); > +    zlen = LZ4_compress_default((const char *)BPTR(buf), (char > *)BPTR(work), BLEN(buf), zlen_max ); You might

Re: [Openvpn-devel] p2p topology on Windows

On Fri, 2016-09-30 at 10:11 +0200, Jan Just Keijser wrote: > > I'm still grappling for the "killer use case" for this - yes, it would be > nice to implement support on all platforms for all > modes, **BUT** I don't think anybody actually uses 'topology p2p' at this > moment (because Windows

Re: [Openvpn-devel] p2p topology on Windows

On Mon, 2016-09-26 at 13:34 +0200, Jan Just Keijser wrote: > > this sounds like a typical use case for "assign a public IP address". > This is already possible with topology subnet and some special config > stuff on the server side, e.g. > - give the openvpn server an IP range that overlaps

Re: [Openvpn-devel] p2p topology on Windows

On Sat, 2016-09-24 at 00:01 +0200, Jan Just Keijser wrote: > > sorry for asking, but what's the use case for this? The use case for point-to-point? It allows you to use a single IP address per client instead of having to set aside a whole /30 subnet per client as with the 'net30' mode. (And in

[Openvpn-devel] p2p topology on Windows

I believe I have P2P working on a Windows (8.1) client (with OpenConnect, but I don't see why it can't work for OpenVPN). I configure the TAP device (with TAP_IOCTL_CONFIG_TUN) with the local IP address, and with network and netmask both of 0.0.0.0. (AIUI this network/mask has nothing to do with

Re: [Openvpn-devel] [RFC] - Enable 2FA to be used with renegotiations

On Thu, 2016-08-25 at 15:45 +0200, David Sommerseth wrote: > > > I've been working a bit on a new patch-set which enables third-party > user/password authentication mechanisms using two factor > authentications [2FA] (such as OTP) and not needing to disable the > renegotiation features of

Re: [Openvpn-devel] [RFC] - Enable 2FA to be used with renegotiations

On Thu, 2016-08-25 at 15:45 +0200, David Sommerseth wrote: > > > I've been working a bit on a new patch-set which enables third-party > user/password authentication mechanisms using two factor > authentications [2FA] (such as OTP) and not needing to disable the > renegotiation features of

Re: [Openvpn-devel] Windows installer with SHA-256 signatures ready for testing

On Mon, 2016-03-14 at 14:18 +0200, Samuli Seppänen wrote: > > >> > > > > Is there a link to the corresponding grub bug? In an ideal world, > > things like the above would never be posted *without* such a link. But > > I suppose we don't necessarily

Re: [Openvpn-devel] Windows installer with SHA-256 signatures ready for testing

On Thu, 2016-03-10 at 16:34 +0200, Samuli Seppänen wrote: > > A second problem should be limited to Windows 7 and Windows Server 2008  > R2 installations that are booted through a non-Windows bootloader (e.g.  > grub): > > Is there a link to the

Re: [Openvpn-devel] Always including tap-windows6, openvpn-gui and easy-rsa in openvpn-build -generated Windows installers?

On Tue, 2016-02-16 at 15:12 +0200, Samuli Seppänen wrote: > Hi, > > Currently openvpn-build allows producing installers which do not  > _contain_ tap-windows6, openvpn-gui or easy-rsa at all. On top of this  > one can - at install time - select which of the contained components are  > intalled. >

Re: [Openvpn-devel] [RFC] --passtos default on/off, and IPv6.

On Mon, 2015-10-26 at 00:15 +0100, Steffan Karger wrote: > On Mon, Oct 26, 2015 at 12:09 AM, Steffan Karger wrote: > > For > > covert channels, it means 23 possible values per 1500-byte packet, or > > ~5 bits for BF, and 12 possible values (~4 bits) for AES-CBC. That is > >

[Openvpn-devel] [RFC] --passtos default on/off, and IPv6.

Since I seem to have accidentally come out of lurk mode anyway... Someone has submitted a patch for OpenConnect¹ to implement something very much like OpenVPN's --passtos option. I prefer to remain consistent with OpenVPN and other tools where possible, so we've renamed the option to

Re: [Openvpn-devel] [PATCH] Use adapter index instead of name

On Thu, 2015-10-22 at 16:17 +0200, Gert Doering wrote: > Hi, > > On Thu, Oct 22, 2015 at 03:09:57PM +0100, David Woodhouse wrote: > > So Olli and Lev would appear to be saying. For OpenConnect I > > haven't > > actually tested this hypothesis. Unfortunately

Re: [Openvpn-devel] [PATCH] Use adapter index instead of name

On Thu, 2015-10-22 at 15:59 +0200, Gert Doering wrote: > hi, > > On Thu, Oct 22, 2015 at 02:55:44PM +0100, David Woodhouse wrote: > > > So what is the underlying issue here? Non-ASCII characters in the > > > device name ("this *should* ha

Re: [Openvpn-devel] [PATCH] Use adapter index instead of name

On Thu, 2015-10-22 at 15:51 +0200, Gert Doering wrote: > Hi, > > On Thu, Oct 22, 2015 at 04:47:56PM +0300, Olli Männistö wrote: > > Many VPN providers like us experience these issues and have to give users > > workarounds to fix it. Here are couple of examples: > >

Re: [Openvpn-devel] [PATCH] Use adapter index instead of name

On Thu, 2015-10-22 at 15:26 +0200, Gert Doering wrote: > > NAK on that - it's extra code, another "two branches that need testing" > addition, and I have not seen any mention of these "weird issues" yet - > so please explain the problem scenario better. > > (I might be happy to go for "use

Re: [Openvpn-devel] Provide a socks5 server port for user apps to use

On Thu, 2015-07-09 at 19:05 -0400, grarpamp wrote: > Having not found this feature and being unfamiliar I'll post > it here simply as FYI for any interested parties. Thanks :) > https://community.openvpn.net/openvpn/ticket/577 http://permalink.gmane.org/gmane.network.openvpn.devel/8478 --

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

On Sun, 2015-05-10 at 00:57 +0300, Alon Bar-Lev wrote: > http://lists.gnu.org/archive/html/gnutls-devel/2011-10/msg00058.html That thread is interesting; thanks for the reference. In it, Stef pointed out¹ that the behaviour of automatically calling C_Initialize() from the atfork child handler is

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

On Sun, 2015-05-10 at 01:09 +0300, Alon Bar-Lev wrote: > > > If an application *knows* that it will never use PKCS#11 after a fork(), > > as in this case where we *know* that we're always just going to exec > > something else, it certainly doesn't *damage* the well-behaved providers > > if we

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

On Sun, 2015-05-10 at 00:57 +0300, Alon Bar-Lev wrote: > Are you sure you want to introduce security issues resulting of > resource leak into the child process? Example: pcsc-lite socket that > is leaking or USB connection? In a way for the child process thus it > being able to access the card?

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

On Sat, 2015-05-09 at 12:17 +0200, Gert Doering wrote: > Hi, > > On Sat, May 09, 2015 at 07:55:56AM -0000, David Woodhouse wrote: > > A better approach would probably be to disable the atfork handlers in > > OpenVPN entirely since I believe we don't need them. > > W

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

> I've spent my evening reading more about vfork() and fork(). I've based > my trust this time in two books [1] on Linux system programming. > > Both books are really clear that vfork() should be avoided, and even > claiming it was a mistake by introducing that syscall in Linux. Its > semantic

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

On Sat, 2015-05-02 at 01:54 +0300, Alon Bar-Lev wrote: > what is specified explicitly in PKCS#11 spec must be applied by > providers, there is no room for interpretation in this specific case. > > > From the OpenVPN point of view, actually there's a cheap trick which > > can let us call it

Re: [Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

rd Holder pin) token", auth_file=0x0, up=0x7ffdb20c8970) at misc.h:272 #10 _pkcs11_openvpn_pin_prompt (global_data=, user_data=, token=, retry=, pin=0x7ffdb20cadf0 "@\260\f\262\375\177", pin_max=1024) at pkcs11.c:235 #11 0x7f26e6ffd0cb in _pkcs11h_session_login (session=0x

[Openvpn-devel] [PATCH] Use vfork() in openvpn_execve() instead of fork()

() and it doesn't matter, and the atfork handlers don't get called for a vfork(). Signed-off-by: David Woodhouse <david.woodho...@intel.com> Trac #538 diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c index 5627cb9..ec14fbc 100644 --- a/src/openvpn/misc.c +++ b/src/openvpn/misc.c @@ -44,6

Re: [Openvpn-devel] [PATCH] Remove useless dash escapes from the man-page

> That would mean we either go into autoconf territory to test for groff > run-time behaviour, or we use a particular unique sequence and do our > own post-processing. The latter is baaically the approach I took in http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/5f15c83f2 --

Re: [Openvpn-devel] [PATCH] Remove useless dash escapes from the man-page

On Tue, 2015-03-31 at 09:19 +0200, Matthias Andree wrote: > I am concerned this will cause misformattings and inability to search > for options with leading dashes on some systems - I don't recall > versions, but I do know that some systems used some sort of Unicode > (soft?) hyphen for a simple

Re: [Openvpn-devel] Where to find tap-win32 documentation?

//git.infradead.org/users/dwmw2/vpnc-scripts.git/blob/HEAD:/vpnc-script-win.js#l166 Btw, Gert, your mailer managed to obliterate '成' (=?UTF-8?B?5oiQ?=) in the To: header of your reply and turn it into '???'. -- David WoodhouseOpen Source Technology Centre david.woodho..

Re: [Openvpn-devel] [PATCH v3] Mac OS X Keychain management client

On Mon, 2015-02-23 at 13:59 +0100, Arne Schwabe wrote: > > All fine. My rationale was like, if I want a certificate with a certain > SUBJECT (e.g. CN=schw...@mycoolca.com) etc. it should not matter for men > wether I get it from OS X, Windows or Android Certificate store. The canonical way of

Re: [Openvpn-devel] the XOR obfuscation

On Wed, 2015-02-04 at 04:41 +0800, 李夏润 wrote: > + size_t keylen = sizeof(key); Perhaps you meant that to be strlen(key), and the problem isn't really that one peer is big-endian, but that sizeof(char *) is different between the two. -- dwmw2 smime.p7s Description: S/MIME cryptographic

Re: [Openvpn-devel] [PATCH] Add more dash escaping to the man page

On Mon, 2015-01-26 at 10:38 +0200, sam...@openvpn.net wrote: > From: Alberto Gonzalez Iniesta > > This patch continues the work started in commit 886593ac4ae ("The man page > needs > dash escaping in UTF-8 environments"). This patch is one of the patches > included > in

Re: [Openvpn-devel] [PATCHv2] Mac OS X Keychain management client

On Mon, 2015-01-12 at 13:54 +0100, Arne Schwabe wrote: > I wonder why only certifcates and not ca certifcates. It would be > logical to get all certifcates from the keychain. Yes, that makes some sense. Although perhaps it should be the other way round — you present the peer's cert to the

Re: [Openvpn-devel] [PATCHv2] Mac OS X Keychain management client

orting key types other than RSA by now. But I appreciate that's not a new limitation and not your fault. It would be interesting to get feedback from those working on NetworkManager-openvpn, which may well want to use this API to allow key operations to happen in the user's session while OpenVPN is

Re: [Openvpn-devel] [PATCH] Add Mac OS X keychain support

On Mon, 2015-01-05 at 13:22 +0300, Vasily Kulikov wrote: > > I see 4 possible alternatives here: > 1) implement keychain rsa offloading in Tunnelblick > 2) make my patch use plugin interface > 3) implement external daemon that communicated with openvpn process via > management interface > 4) the

[Openvpn-devel] [PATCH 2 v3] Make 'provider' option to --show-pkcs11-ids optional where p11-kit is present

Trac: 490 Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- v2: Nicer error message if no provider given when there's no default. v3: Get the usage messages the right way round (s/ifndef/ifdef). I did look at cleaning it up to stop looking at p[2] even when p[1] isn

[Openvpn-devel] [PATCH 2 v2] Make 'provider' option to --show-pkcs11-ids optional where p11-kit is present

Following on from the previous patch, this fixes --show-pkcs11-ids too. Trac: 490 Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- As I compose the email, I spot that we're actually now looking at the value of p[2] even when p[1] is NULL. So if the add_option() function is su

Re: [Openvpn-devel] [PATCH 2] Make 'provider' option to --show-pkcs11-ids optional where p11-kit is present

On Tue, 2014-12-16 at 22:19 +0100, Steffan Karger wrote: > > Since this makes a '--show-pkcs11-ids' without the module argument > valid > for some openvpn builds, I think it is nicer to give a proper error > message to the user. E.g. something like: Like this? If this incremental patch is what

[Openvpn-devel] [PATCH 2] Make 'provider' option to --show-pkcs11-ids optional where p11-kit is present

Following on from the previous patch, this fixes --show-pkcs11-ids too. Trac: 490 Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- doc/openvpn.8 | 8 +++- src/openvpn/options.c | 21 - 2 files changed, 27 insertions(+), 2 deletions(-) diff

[Openvpn-devel] [PATCH] pkcs11: Load p11-kit-proxy.so module by default

If the user specifies --pkcs11-id or --pkcs-id-management but neglects to explicitly provide a --pkcs11-provider argument, and if the system has p11-kit installed, then load the p11-kit proxy module so that the system-configured tokens are available. Trac: 490 Signed-off-by: David Woodhouse

[Openvpn-devel] TAP-Windows MTU issues

It looks like on Windows, OpenVPN ignores the MTU it's supposed to be using and just queries the TAP driver for its MTU. I suspect this was done in the past because there was no way to *set* the MTU that Windows was expected to use. That is no longer the case; recent versions of Windows let you

Re: [Openvpn-devel] Any Windows-based OpenVPN servers available for fixing bug #432?

indows device driver" thing is magic for me. > > > > gert > > Apparently 2.x is not handling certain tap-windows6 return/error codes > correctly. According to Thomas that is causing several of the issues > we've experienced with tap-windows6. Do you have specifics,

Re: [Openvpn-devel] Tap-windows6 (NDIS 6) installer available for testing

On Tue, 2014-04-15 at 19:59 +0300, Samuli Seppänen wrote: > The driver has been tested on Windows 7 64-bit and it "seems to work > ok". If you test this driver please let me know if it works - or if it > does not. I've finally got round to testing this with OpenConnect, also under Windows 7

[Openvpn-devel] MTU handling on Windows

On Windows 7 at least you can set the MTU with netsh: netsh interface $PROTO set subinterface $TUNDEV mtu=$MTU store=active Where PROTO is 'ipv4' or 'ipv6' and the others are even more obvious. OpenVPN doesn't appear to do this; it seems to leave the MTU untouched and instead query the TAP

Re: [Openvpn-devel] Wanted: NTLM-Testers

On Tue, 2014-06-24 at 18:46 +0200, Holger Kummert wrote: > Hello David, > > thanks for taking time and reviewing and testing the code. > > Am 23.06.2014 16:23, schrieb David Woodhouse: > > Looking over the patches first... they make the client work in OEM or > > Uni

Re: [Openvpn-devel] [PATCH] cstp: Add workaround for 255.255.255.255 netmask on windows

+ data[2] = htonl(0xfffe); data[1] = data[0] & data[2]; if (!DeviceIoControl(tun_fh, TAP_IOCTL_CONFIG_TUN, -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7

Re: [Openvpn-devel] TAP adapter detection

On Thu, 2014-04-17 at 17:01 -0400, Greg Toombs wrote: > Found the problem. tun-win32.c:45 - > #define TAP_COMPONENT_ID "tap0901" > > This is only valid for the most recent version of the TAP adapter. For > other versions, this should actually be "tapoas". So openconnect > saying that there are no

Re: [Openvpn-devel] [PATCH 0/3] Support non-root operation using ocproxy

we'd consider that a violation of the philosophy. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature

Re: [Openvpn-devel] Failure to configure TAP device under Windows

On Wed, 2014-02-12 at 12:11 +0100, Gert Doering wrote: > > It actually *should* work just fine. Thanks for the response. > I've never used the control panel to set up IPv6 addresses, but using > netsh worked nicely for me (and OpenVPN) - look into the openvpn sources > to see the necessary

[Openvpn-devel] Failure to configure TAP device under Windows

I installed OpenVPN on Windows 7 64-bit using openvpn-install-2.3.2-I003-x86_64.exe and ported the OpenConnect VPN client¹ to use the TAP device. It created a TAP device as part of the installation, named 'Local Area Connection 3'. Attempting to configure IP addresses on this device fails thus: