Re: FWD: [PATCH] (Fixed) Support for openvpn --auth option

[Robert Vogelgesang <vogel users sourceforge net>]

Hello,

On Fri, Dec 19, 2008 at 06:15:24PM -0500, Dan Williams wrote:
[...]
> (rant) Sensible solutions include a negotiation phase where the client
> and server agree on a set of parameters *during the process*.  That way,
> users don't have to set this crap manually.  Apparently, the OpenVPN
> developers aren't interested in making their software actually usable.
> The number of options is staggering, but worse than that, you have to
> know *exactly* how the server is set up to connect, otherwise you simply
> fail.  That's not how you make usable software.

Yes, I hope that we do not have to support each and every openvpn option
in the GUI.  But we should make sure that each option that _is_
supported in the GUI is also supported when importing openvpn config
files (which I did in my patch).

[...]
> > > For minimal impact, I choose to implement the --auth option in the
> > > same way as the --cipher option.  Both the "new" --auth and the "old"
> > > --cipher options share the following issues:
> > > 
> > > o	When a non-default value was saved and you want to switch back
> > > 	to "Default" later on, then this change does not get saved and
> > > 	the non-default value remains in the config.
> > > 
> > > 	As far as I understand the plugin code, this issue seems to be
> > > 	caused by NetworkManager or gconfd, not by the openvpn plugin
> > > 	(the hash returned by advanced_dialog_new_hash_from_dialog() does
> > > 	not contain the --auth/--cipher value when "Default" was chosen).
> > > 
> > > 	Is this a known issue?  (bugzilla.gnome.org didn't show anything
> > > 	similar for NetworkManager)
> 
> That should be handled in nm_gconf_set_stringhash_helper() in
> src/gconf-helpers/gconf-helpers.c, where keys not in the hash table get
> deleted from GConf.  If the parameter is the default value, it shouldn't
> show up in GConf at all, as you see by
> advanced_dialog_new_hash_from_dialog() returning a hash table without
> that key in the table.  Could you check to see if the non-default value
> key is correctly getting removed from GConf by the code in
> nm_gconf_set_stringhash_helper()?

I don't know what nm_gconf_set_stringhash_helper() does, but I checked
the xml file written by gconfd in a subdirectory of the user's home.
When setting "auth" or "cipher" to "Default" in the GUI, the previous
value was not removed from that file.

I will re-check after having upgraded my patch to the freshly
released NetworkManager-openvpn-0.7.0-16.svn4326.fc9, which is first
priority for me now, because after updating all the other
NetworkManager rpms, my VPN connection does no longer work.


> > > o	Openvpn supports these options for both static and TLS modes.
> > > 	The openvpn plugin for NetworkManager carries the --cipher option
> > > 	(and with my patch, the --auth option, too) on the "Certificates
> > > 	(TLS)" tab of the "advanced" popup, which is only available when
> > > 	using TLS modes and not when using static keys.
> > > 
> > > 	The easiest fix would be to move the popup-menue(s) (GtkComboBox)
> > > 	for --cipher (and --auth) to the "General" tab.  A little bit more
> > > 	work, but maybe better for future extensions:  Introduce a new
> > > 	tab "Encryption" for these options.  What do you think/prefer?
> 
> How about we name it "Security" instead?  I'd take a good look at a
> patch that did that.

OK, fine.

> 
> > > 
> > > I'm willing to fix the second issue and to do some more research on the
> > > first one if there is a real chance that support for the --auth option
> > > of openvpn gets accepted into the NetworkManager distribution.  ;-)
> 
> Yeah, that would be great if you could.  Thanks!
> 
> Dan
> 

As stated above, the next step for me is to get my VPN working again,
with Fedora 9 and all current updates.  I'll post the new patch as
soon as possible, but it may take a week or so, because I will be
"offline" during the holidays and possibly the next weekend, too.

I see that the latest updates for Fedora 9 and Fedora 10 both have
the same version of NetworkManager, so I think that developing with
Fedora 9 is good enough.  Or is there any NetworkManager-related reason
to upgrade first?  (i. e. to Fedora 10)

	Robert