The Settings.Connection interface is now only provided by NetworkManager
itself since there is only one settings service. NM can validate
requests for secrets internally and thus there's no need to lock down
GetSecrets using a separate D-Bus interface, since PolicyKit provides
that functionality on systems where this is desirable (ie multi-user).
Single-user systems that do not have PolicyKit will inherently trust
the user already, or if not D-Bus auth is flexible enough to lock
down the GetSecrets method individually even if it's not on a separate
D-Bus interface.
Second, since only clients like connection editors or applets will be
calling the GetSecrets method, there's no need for 'hints' or
'request_new' arguments here since this method should never trigger
an interactive secrets request. Only NM should send those requests
when it knows it needs to ask the user, either during connection or
after validating the incoming GetSecrets request. A connection editor
type application should never be able to trigger the normal
"What's your passphrase" dialog thats provided by the secret agent
for that user's session.
The current agent isn't in the 'pending' list, so don't check
the list for the agent and bail if it's not found since that
won't handle the current agent going away.
Allows NM to signal to an agent that an in-progress secrets
request is no longer needed. This could happen if the device
for which the request was started was removed, disabled, or the
network being connected to changed, or whatever.
Filter registered agents for each secrets request to ensure that the
connection for which secrets are requested is visible to that agent,
and add that agent to the queue. Ask each agent in the queue until
one returns usable secrets. Ensure that if new agents register
or existing agents quit during the secrets request, that the queue
is updated accordingly, and ensure that an agent that's already
been asked for secrets, unregisters, and re-registers before the
secrets request is comple, isn't asked for secrets twice.
Instead of a bizare mechanism of signals back to the manager
object that used to be required because of the user/system settings
split, let each place that needs secrets request those secrets
itself. This flattens the secrets request process a ton and
the code flow significantly.
Previously the get secrets flow was something like this:
nm_act_request_get_secrets ()
nm_secrets_provider_interface_get_secrets ()
emits manager-get-secrets signal
provider_get_secerts ()
system_get_secrets ()
system_get_secrets_idle_cb ()
nm_sysconfig_connection_get_secrets ()
system_get_secrets_reply_cb ()
nm_secrets_provider_interface_get_secrets_result ()
signal failure or success
now instead we do something like this:
nm_agent_manager_get_secrets ()
nm_agent_manager_get_secrets ()
request_start_secrets ()
nm_sysconfig_connection_get_secrets ()
return failure or success to callback
