On Tue, Feb 28, 2012 at 8:25 PM, David Sommerseth <openvpn.l...@topphemmelig.net> wrote: >> This is *THE* missing functionality in Windows environment. It seems >> that nobody interested in developing proper UI using management >> interface for Windows. Same goes to proper smartcard support. > > I believe Jan Just Keijser and Heiko talked about this as well at FOSDEM, > how to provide a better integrated PKCS#11 support in the Windows GUI. > So I would expect this to progress too. And of course, the new GUI Heiko > writes is using the management interface too, anything else would be > plain stupid these days.
Right. I don't know what he is writing. Anyway, the message I sent today regarding the external key is the root. Adding functionality to set the certificate via the management have the potential to resolve the whole issue. > Even though, the new communication pipe between the "helper service" and > openvpn.exe might gain more features with time, which might cover much > of what the management interface provides today too. But we're _not_ > trying to kill the management interface. There is no need for the helper service. Nobody care if the openvpn daemon is running in privilege mode. The problem is the user interaction. So I would have avoided to invest resources at the daemon side and invest resources at proper UI. >> In Linux I am using OpenVPN using unprivileged user (completely!) the >> daemon runs under my own user, see[1]. > > This new communication pipe should also become available for the *nix > platform too. Which again should make it easier to implement something > which does not depend on a safe sudo setup too. Maybe even some > integration against NetworkManager via DBus for the Linux platform? dbus is way too fragile, it is good for desktop... not for core components. And... requiring network manager (large piece of software) only for iproute2 replacement is redundant. The management interface is great. Again, the main problem is not the daemon but the user. I went one step farther and wrapped the iproute2... this is optional. > I'm at least playing with the idea that OpenVPN itself shouldn't > necessarily need to know much about how to configure the TUN/TAP device > and routes for all different platforms. Rather write platform specific > "service helpers" which does that job via the the communication pipe. > > This would make the OpenVPN code base simpler and perhaps even easier to > support more platforms, like Android - and maybe even iPhone and the new > Windows Mobile? Well, this can be done now, just wrap the iproute with suid program to do whatever you like, this is the wrapper. The tap device can be accessed using non-privileged user, so all that is left is the iproute2 delegation. This does not require special code or effort. Bottom line: the management interface is great. One missing functionality is setting certificate. Effort should be invested in proper UI to leverage the management interface. Running openvpn *DAEMON* as completely unprivileged is 2nd priority. On Linux it can be done by simply wrapping the iproute2 executable, using sudo/dbus whatever to achieve same functionality. On Windows a similar solution may be provided. Alon.
