This allows a device (or a companion) to signal that it is not a good
time for a specific device to autoconnect to a network.
The OLPC mesh device will use this to prevent automatic connection
to WLAN networks while the mesh device is active.
Like the OLPC mesh interface, which uses the same actual MAC & radio
as the OLPC wifi device, and thus when mesh is active the wifi
shouldn't be scanning.
The DBusGProxy was getting destroyed after all the ListConnections calls
were completed, and thus the dbus match was removed, and the signals
weren't getting reflected back up into NM to be handled. Fix that by
attaching the DBusGProxy to the NMConnection it represents to ensure it
lives until that NMConnection dies.
Found by Ricardo Salveti de Araujo <ricardo.salveti@openbossa.org>
The link cache was updated immediately, but the carrier state signals
were emitted a lot later, when the cache data was already stale. So
just update the cache at the same time we emit the signals. The
carrier-state-request stuff wasn't originally converted to deferred
for any netlink-specific reason, just to smooth the initial device
creation process in NM.
PK < 1.0 doesn't work with UID 0 processes that aren't spawned via a
session-manager, and thus don't have the XDG_SESSION_COOKIE in their
environment (which ConsoleKit uses to figure out what session the
caller is in). But since root could just scribble over the config
files anyway, bypassing PK for UID 0 doesn't meaningfully decrease
security.
The only thing that doesn't work yet is the system-settings service's
"auto eth" connections for ethernet devices that don't have an existing
connection. Might also have issues with unmanaged devices that can't
provide a MAC address until they are brought up, but we'll see.
Plugins no longer need to hash WPA passphrases, so there's no need to keep
sha1 stuff around unless its for hasing other stuff (ifcfg-rh uses sha1
for certificate hashing for example, but has a private copy).
Leave it to wpa_supplicant now; if we can't trust the supplicant to
handle this, then we need to fix the supplicant. It knows better than
us what needs to happen with drivers, and it already clears the
encryption keys anyway.
