Since openSUSE 11.1 NetworkManager does not support reading yast network
setup. It's for your own good - you either want to use static configuration
(yast) or dynamic (NetworkManager). Mixing the two has never worked very well
and has caused a lot of confusion. The only exception to this is hostname
handling, which is handled by ifcfg-suse plugin.
Since one test read in a file, wrote it out, and read it in again, we
have to be careful of whether srcdir == builddir or not. If it doesn't,
then we need to remove the written-out connection file. If it does, then
we don't want to remove that written-out connection file because it's
tracked by SCM. Avoid the whole problem by writing it out to a separate
directory that we can always delete it from.
And remove cargo-culted internal stuff which is no longer needed.
The ifcfg-rh sha1 stuff wasn't even used anymore after the move to
certificate paths.
nm_connection_replace_settings() replaces the connection's settings
but doesn't allow interception of the new settings. Plugins would then
send out the update signal, but secrets are scrubbed out of them to
ensure secrets aren't leaked out into D-Bus signals.
With NM 0.8 the system settings service was integrated into NM and
thus nm_connection_clear_secrets() acts directly on the system
settings plugins' NMConnection objects. So when NM cleared secrets
(for example after determining that they might be bad in a device's
stage2 handler), we completely lost the secrets forever.
Adding this function allows the system settings service to hook into
the connection updates when the plugin connection's backing storage
(like config files or whatever) changes and cache the secrets for
use in NMSettingsConnectionInterface get_secrets() requestes.
To be backwards compatible clients need to handle both paths to private
keys and the decrypted private key data, which is what used to get passed
in the private-key and phase2-private-key attributes of the 802.1x setting.
When moving a connection around between system-settings and user-settings,
if the private key is decrypted data, the settings service needs to store
that decrypted data somewhere so that the key can be sent to NM during
the connection process.
But we don't want to store the decrypted private key data, so we have to
re-encrypt it (possibly generating a private key password if one wasn't
sent with the decrypted data) and save it to disk, then send NM a path
to that private key during connection.
To help clients do this, and so that they don't have to carry around
multiple crypto implementations depending on whether they want to use
NSS or gnutls/gcrypt, add a helper to libnm-util.
Furthermore, I misunderstood a bunch of stuff with crypto padding when
writing the encrypt/decrypt functions long ago, so fix that up. Don't
return padding as part of the decrypted data, and make sure to verify
the padding's expected lengths and values when decrypting. Many thanks
to Nalin Dahyabhai for pointing me in the right direction.
Overload the certificate and key properties to allow paths to the
certificates and keys using a special prefix for the property data.
Add API to libnm-util for easy certificate path handling, and
documentation for NMSetting8021x.
Make NMSettingsService implement most of the NMSettingsInterface
API to make subclasses simpler, and consolidate exporting of
NMExportedConnection subclasses in NMSettingsService instead of
in 3 places. Make NMSysconfigSettings a subclass of
NMSettingsService and save a ton of code.
The old NMExportedConnection was used for both client and server-side classes,
which was a mistake and made the code very complicated to follow. Additionally,
all PolicyKit operations were synchronous, and PK operations can block for a
long time (ie for user input) before returning, so they need to be async. But
NMExportedConnection and NMSysconfigConnection didn't allow for async PK ops
at all.
Use this opportunity to clean up the mess and create GInterfaces that both
server and client objects implement, so that the connection editor and applet
can operate on generic objects like they did before (using the interfaces) but
can perform specific operations (like async PK verification of callers) depending
on whether they are local or remote or whatever.
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).
The plugin called nm_exported_connection_update() which ended up checking
PolicyKit for authorization to update the connection, which of course fails
completely when it's just an inotify-triggered update. inotify-triggered
updates don't need authorization because they require root access anyway.
