On Jun 27, 2014, at 12:00 PM, Jukka Rissanen <jukka.rissa...@linux.intel.com> wrote: > On to, 2014-06-26 at 16:52 -0700, Drew Stebbins wrote: >> Hi folks, >> >> I'm working on a project where devices on a WiFi network must occasionally >> provide an application with the WiFi network's security credentials. These >> credentials are used to provision new devices via an alternate >> communication mechanism. For consistency's sake, I'd like for the >> application to get these credentials from ConnMan via D-Bus. For now, I've >> added a "Passphrase" property back to the D-Bus service dictionary for WiFi >> networks. This property was previously removed back in commit >> eff06f8e1ce3c3dcf5a3d8158d01403ecf6d62a8. > > Although the Passphrase is not very secret information it was too easy > to get it via dbus without any apparent real use case in mind. That is > probably why it was removed from dubs.
Certainly the one use case that was prevalent around the time of this refactor was agent support. In the particular use case where an old PSK fails and the agent interface prompts the client for a new one, the old PSK is provided in an adjunct dictionary for the purposes of rendering it directly or substituted by bullets (•) in a GUI. >> The above commit would seem to imply that sensitive information such as >> passphrases should be kept out of the publicly-visible service dictionary. >> If so, how would the community suggest ConnMan expose network credentials >> to an application? I'd like to upstream this functionality if at all >> possible, as I suspect I'm not the only one with this sort of use case. > > What kind of use case you have in mind? Also note that most people would > probably not want to expose this information via dubs. > > If you are really eager to get passphrase information, you can always > dig the settings files in /var/lib/connman directory. Imagine a deeply-embedded system with WiFi in which there is no physical user interface on the device whatsoever. Now, imagine an out-of-band channel in which a mobile device, with appropriate authorization over that out-of-band channel, would like to extract the currently-provisioned WiFi services for the purposes of provisioning another new system. Imagine another system, different from a mobile device, perhaps like the first that can communicate and authenticate with it out-of-band, based on some provided user authority. Over that channel, the first device would like to tell the second, "When you encounter this WiFi network, you may connect to it with these credentials.". While you're correct that one could certainly root about int he /var/lib/connman directory and pull this, such a mechanism will not survive connman version changes due to a high-reliance on internal details that are subject to change by virtue of being not being part of connman's public API. Perhaps there could be a config option, deserted by default, that allows this property to be exposed when that configuration is asserted? Best, Grant _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
