Hi Marcel, On Wed, May 23, 2012 at 7:20 AM, Marcel Holtmann <[email protected]>wrote:
> Hello, > > with the ConnMan 1.0 release we introduced a purely agent based handling > of passphrases. The term passphrases here applies to WEP and WPA/WPA2 > pre-shared keys. ConnMan does store (and only these) by itself so they > are available when attempting to reconnect. And we do store them since > there is no point in trying to protect something that is not bound to a > user or actually extra secure. They are pre-shared keys in the first > place. > > Now the question now arises on how to handle the case where the > passphrase inside an access point got changed and the next connection > attempt will fail. Currently we just request a new passphrase from the > user. However the user experience requests prefers to be able to show > the user the previous passphrase or at least a starred out version of > it. And I tend to agree with this. > > The idea would be that the agent request adds an informational category > and we can provide the old passphrase value. > > Sounds good to me. but will we prompt the passphrase on every connection attempt or just when we get a invalid key error? I really dont like NM when it pops up the passphrase dialogue everytime i connect to a known AP. Another option is to forget the network/remove the service on an invaid-key error. > For a single user embedded system this seems to be perfectly reasonable > and would make the UI development a lot simpler. So I am all for it. The > question that arises is if we might need a main.conf option to disable > such behavior in a multi-user setup of for system that have a different > security policy. Reason behind is that we do not generally control who > registers as an agent. On a single user system it will be always the > same user interface, but on a multi-user system this might not be the > case. > > And keep in mind this is purely about passphrases. Username/password > requests for WISPr or WiFi Enterprise or VPN credentials will be always > an user input and requested every time. ConnMan does not store these. > > Any thoughts? > > Regards > > Marcel > > > Cheers, Alok. > _______________________________________________ > connman mailing list > [email protected] > http://lists.connman.net/listinfo/connman > _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
