Remove some registry keys/options and use file association for open/edit

[selvanair]

Note on commit 2: Use file associations to open config and log
Works fine on my win7 test machine, but more independent testing would help. Note that notepad is the default editor, so associate with something else to test.

Full commit messages:

1. Simplify some parameters and registry keys

• Replace allow_password by a runtime check that enables password
  change menu only when the user has write-access to the key file.
• Read exe_path and priority from HKLM and do not duplicate in HKCU.
• Always allow the user to view the config: edit will succeed if user
  has write access.
• Always include the proxy settings tab which is the default.
• Remove the unused power event handling and disconnect_on_suspend key.
• Remove password_attempts -- user can stop the password dilaog
  by clicking cancel.
• Remove allow_service: implicitly enabled if service_only is used.
• Deprecate removed options in cmd-line parser
• Update README.rst

1. Use file associations to open config and log

• Use ShellExecute to open config and log files so that
  file associations can be used. If that fails fall-back to
  the default editor (notepad.exe).
• Remove the keys editor and log_viewer from registry.
  The user can change the editor/viewer through fie association.

[mattock]

As discussed in #61 I tested openvpn-gui.exe that has these changes, and it worked as expected. The changes are reasonable imho, so a feature-ACK from me. Having a code-ACK would be good to have, so that we don't again have to resort to lazy-ACK.

[chipitsine]

it also makes sense to change behaviour of "Replace allow_password by a runtime check that enables password change menu only when the user has write-access to the key file"

(I never had a time for that, actually)

if someone running login/password (Active Directory, for instance) auth, there's still password change menu which ends with

  if ((!found_key) && (!found_pkcs12))
    {
      /* must have key or pkcs12 option */
      ShowLocalizedMsg(IDS_ERR_HAVE_KEY_OR_PKCS12);
      return(0);
    }

it makes sense to hide "password change menu" in such case, i.e. check if ((!found_key) && (!found_pkcs12)) before building menu list

[chipitsine]

also, UI in "change password" is not very good.
people do not make sense what is it about.

[selvanair]

@chipitsine : If key or pkcs12 file is not found the menu will not be inserted and no error message will be shown. The code snippet you quoted is from the current master, not my patch. The original code is not capable of changing password in inline key/pkcs12 files and that limitation still holds.

Could you please test the patch and see whether it works? There is a binary at https://github.com/selvanair/openvpn-gui/releases/tag/v11.0-registry-test (this includes the proposed option editing dialogs as well).

You are right, the UI is confusing as it does not clarify this passphrase refers to that of the private key, not auth-user-pass. We could change the menu text.

[chipitsine]

sure, I will test patch.

I vote for "protect private key with password" instead of "change password"

[selvanair]

Rebased to master and added a commit implementing dialogs for editing options saved in registry. Now only non-default values saved in the registry. (as discussed here [https://github.com//issues/61]).

[mattock]

@selvanair: is there an openvpn-gui.exe that includes your latest changes?

[selvanair]

@mattock: Yes, see here

[mattock]

@selvanair: great, I will test this tomorrow. I have some other Windows testing in the queue anyways.

[mattock]

It seems I had tested this earlier and had reported my findings in issue #61, so I only did light testing of openvpn-gui-pr64.exe. Based on that I can verify that the registry values are written only if they're modified by the user. Once a key is in the registry, it remains there, even if it's value is later reverted to the default by user. I think this behavior is reasonable, although have a "Reset to defaults" button might be useful to have, now that people actually can change the configuration easily.

As for "change password" - I did not see that menu item, but depending on the context chipsine's suggestion "protect private key with password" could work. Another option would be "change private key password".

[mattock]

Note to self: close https://community.openvpn.net/openvpn/ticket/494 once this PR has been merged.

[selvanair]

@mattock : thanks for testing.

• For the "reverting to default" case I chose to keep the value in registry in such cases. The assumption is that any edits mean the user has a preference and even if future defaults changes it should be respected. But I'm open to change this to remove if reverted to default.
  A reset to defaults (except language and proxy?) button will indeed be useful. Will add it to my TODO.
• For change password, its now shown only if password change is likely to succeed. Inline key files will not activate it as the current code is not capable of changing the password in such cases. It should show up if you use an external key file and the file is readable.
• I vote for "Change Private Key Password". This could be handled in a separate patch along with translations..

Edit: s/readable/writeable/

[cron2]

Hi,

On Wed, Aug 17, 2016 at 07:46:14AM -0700, Selva Nair wrote:

• I vote for "Change Private Key Password". This could be handled in a separate patch along with translations..

+1 :)

gert

USENET is not the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de

[mattock]

👍

[selvanair]

@mattock : Shall we "lazy-ack and merge" this? The proposed improvements such as menu for reverting options to default could be tackled in another PR.

[mattock]

Yes, makes sense. I'll merge it now.