If a request isn't found in shell_network_agent_set_password() or
shell_network_agent_respond(), then g_return_if_fail() rather than
crashing. OTOH, if a request is not found in
shell_network_agent_cancel_get_secrets(), then just ignore it
silently, since that could legitimately happen.
https://bugzilla.gnome.org/show_bug.cgi?id=674961
When the operation is cancelled by NetworkManager, the request is
cancelled immediately. Later when gnome-keyring invokes the callback
notifying the error we must therefore not access its memory.
Previously the callback would mistakenly treat "cancelled" (which
indicates a programmatic cancel) as "denied" (which means the user
clicked "Cancel" on the keyring prompt)
https://bugzilla.gnome.org/show_bug.cgi?id=658484
VPN secrets are stored by the plugins, that provide separate
helpers for authentication. This commit adds the support for invoking
the binaries and pass them connection details.
For plugins that support it (as exposed by their keyfile), we invoke
them in "external-ui-mode" and expect a set of metadata about the
secrets which is used to build a shell styled dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=658484
VPN secrets are currently unhandled by the UI code. To avoid
lengthy timeouts, bail out early with an error, so NetworkManager
falls back to the nm-applet agent directly.
https://bugzilla.gnome.org/show_bug.cgi?id=658484
A network agent is a component that stores network secrets (like
wifi passwords) in the session keyring. This commit adds an
implementation of it to be used by the shell network dialogs. It
handles most of the keyring stuff, delegating the UI to upper layers.
https://bugzilla.gnome.org/show_bug.cgi?id=650244
