Thanks Grant for the reply. The config option sounds right to me as a general solution. Connman folks, thoughts?
Thanks, Drew On Fri, Jun 27, 2014 at 12:27 PM, Grant Erickson <[email protected]> wrote: > On Jun 27, 2014, at 12:00 PM, Jukka Rissanen < > [email protected]> 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 [email protected] https://lists.connman.net/mailman/listinfo/connman
