Re: SecretAgent.GetSecrets() return value

[Daniel Drake <dsd laptop org>]

On Tue, Sep 6, 2011 at 11:20 PM, Dan Williams <dcbw redhat com> wrote:
> Like you say if a secret is wrong or needs to be changed, there's no
> facility to ask for that secret.  We can (and should) make sure NM would
> fail the connection with a NM_DEVICE_REASON_NO_SECRETS or something like
> that if NM can find out the secrets are wrong, which could trigger the
> applet to toss up the "your connection failed, please re-enter your PSK"
> dialog or whatever.
>
> Or, if you use a secret agent, NM will ask for the secrets when it
> thinks it needs them.

I think I'll go with the secret agent option for now, as it doesn't
require immediate NM work, and as you say, it is quite easy to morph
the NM-0.8 implementation into a SecretAgent, and it really doesn't
need much code (only GetSecrets). I think this may even be the more
simplistic option, as it offloads all the tricky "do I need secrets
right now?" logic to NM.

> Return value should be a hash table of hash tables (basically an
> NMConnection of only the secrets), so for example if you're returning a
> WPA-PSK connection's secrets, it would be simply:
>
> wsec = { 'psk': 'some-really-secure-psk' }
> hash = { '802-11-wireless-security': wsec }
> return hash

Thanks for the clarification.

What would happen if a WEP connection was originally added with
auth-alg='open', but then in my GetSecrets response, I give:

wsec = { 'wep-key0': 'some-unsecure-key', 'auth-alg': 'shared' }
hash = { '802-11-wireless-security': wsec }

Would NM then use shared or open authentication?
('shared' is what would be desired, for the context of this see
http://mail.gnome.org/archives/networkmanager-list/2009-December/msg00018.html
)

Thanks,
Daniel