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.
Fixes a bug where if GSM secrets were required, the connection would fail
because they were requested with SECRETS_CALLER_HSO_GSM, but the function
to handle retrieved secrets only expected SECRETS_CALLER_GSM.
- Re-query the BlueZ manager when connection, or connections are
added
- Don't assert when a new BT device is created
- Fix the connection bdaddr and device bdaddr comparison, we
were comparing a byte array with a string
- Simplify bluez_manager_bdaddr_has_connection()
- Use NM_BT_CAPABILITY_NONE instead of 0 when appropriate
- Don't assert on priv->bt_type not being set in
real_deactivate_quickly(), as it might be called with no
connections activated
- Fix cut'n'paste typo that made setting the device capabilities
assert
Create a new exported Bluetooth device object for any usable Bluez device
that has at least one corresponding NMConnection somewhere. Clean up
UUID/Capability confusion too.
NMSettingBluetooth represents the local connection, and thus should
use "PANU" not NAP, because the local adapter will be in PANU mode.
For now, NAP is only relevant when talking about the *remote* device
in NMDeviceBt or NMBluezDevice.
