Because most of the time they will. They need special handling all
around anyway because only the VPN plugin itself knows whether the
connection needs secrets.
The old function took a string value, which wasn't really correct as
the property type is a GHashTable of string:string. For whatever
reason this is how nm-applet passed VPN secrets back to NM in the return
from the GetSecrets() D-Bus call. This was probably easier or
something but it was a special case that's magic and quite unclear.
Since we use nm_connection_update_secrets() more these days, and we
depend on the GValue types we pass into it matching the property
types of the setting property the secret is for, we need to fix that
up for VPN connections. But keep the old code for backwards
compatibility.
In the future secret agents should pass back VPN secrets in the same
form as the VPN setting specifies them for the "secrets" property:
a GHashTable of string:string. But the old mechanism of just dumping
the key/value pairs into the returned VPN hash as string:string will
still work.
Do the check for system-owned secrets once, before kicking off the
request, instead of each time we ask an agent. As a bonus, this
change ensures priv->secrets doesn't store anything except
system-owned secrets too, simplifying some checks later on.
Not all connections will require every secret, and sometimes we
can't automatically figure out whether we need the secret. For
vpnc sometimes the group password isn't used, and sometimes PPP
providers require a username but don't want a password, etc.
Just because the key isn't saved (ie, the user hasn't entered it yet,
or the user want to type it in every time) doesn't mean the setting isn't
WEP, so recognize it as WEP if DEFAULTKEY or SECURITYMODE is set.
If we can authenticate the agent for 'modify' permission, then send
any existing system secrets to it as the user has permission to change
those secrets. This means the agent doesn't have to call GetSecrets()
itself, which means simpler code on the agent side for a slight LoC
hit in NM itself.
This also moves the permissions checking into the NMAgentManager to
check each agent, which is sub-optimal since now the agent manager
has to do PolicyKit stuff, but hey that's life. Agents need secrets,
and we do need to authenticate every agent before we send secrets to
them, and the NMSettingsConnection doesn't know about individual
agents at all.
If the agent returns system-owned secrets, like when activating a new
connection which was created with no secrets, make sure the agent is
authorized to modify network settings before saving or using the
new secrets.
Becuase there's only one 'flags' property for WEP keys (because it's pretty
dumb to have different flags for all 4 WEP keys) we need to do some tap dancing
with the secret name, so that requests for "wep-keyX" look up the "wep-key-flags"
property.
Duh, AND-ing flags with 0 (which is NM_SETTING_SECRET_FLAG_SYSTEM_OWNED)
is always going to be FALSE... NM_SETTING_SECRET_FLAG_SYSTEM_OWNED is
special; because it's the default value if the key isn't present,
and at this point it's exclusive of all other flags. So (at least for
now) it's OK that it's 0 but we might want to change it later so that
NM_SETTING_SECRET_FLAG_SYSTEM_OWNED can actually be used as a flag.
This allows the necessary flexibility when handling secrets; otherwise
it wouldn't be known when NM should save secrets returned from agents
to backing storage, or when the agents should store the secrets. We
can't simply use lack of a secret in persistent storage as the indicator
of this, as (for example) when creating a new connection without
secrets the storage method would be abmiguous.
At the same time, fold in "always ask" functionality for OTP tokens
so user agents don't have to store that attribute themselves out-of-band.
There was never a property for it anyway, so it never got serialized
across D-Bus, because it was folded into the "password" property in
wpa_supplicant between 0.5 and 0.6.
It's the thing that owns the secrets anyway, and it simplifies things to
have the secrets handling there instead of half in NMActRequest and
half in NMManager. It also means we can get rid of the ugly signals
that NMSettingsConnection had to emit to get agent's secrets, and
we can consolidate the requests for the persistent secrets that the
NMSettingsConnection owned into NMSettingsConnection itself instead
of also in NMAgentManager.
Since the NMActRequest and the NMVPNConnection classes already tracked
the underlying NMSettingsConnection representing the activation, its
trivial to just have them ask the NMSettingsConnection for secrets
instead of talking to the NMAgentManager. Thus, only the
NMSettingsConnection now has to know about the agent manager, and it
presents a cleaner interface to other objects further up the chain,
instead of having bits of the secrets request splattered around the
activation request, the VPN connection, the NMManager, etc.
