Neither gnutls nor NSS fully support PKCS#8 so we don't have complete
support here, but at least recognize the keys and make an attempt to
check the private key if we can.
By 'base type' I mean a hardware-related type that can actually be used
to activate the connection, like wifi, wired, gsm, cdma, wimax, bluetooth,
etc, but not ipv4, ipv6, 8021x, etc.
It's easier to be able to pass both a whole hashed connection, or just
a hashed setting to the function, and have it figure out what needs
to be updated based on the given setting_name.
Add some testcases to make sure that all works correctly too.
First, it was not easily possible to set a private key without
also providing a password. This used to be OK, but now with
secret flags it may be the case that when the connection is read,
there's no private key password. So functions that set the
private key must account for NULL passwords.
Unfortunately, the crytpo code did not handle this case well.
We need to be able to independently (a) verify that a file looks
like a certificate or private key and (b) that a given password
decrypts a private key. Previously the crypto code would fail
to verify the file when the password was NULL.
So this change fixes up the crytpo code for a more distinct
split between these two operations, such that if no password is
given, the file is still checked to ensure that it's a private
key or a certificate. If a password is given, the password is
checked against the private key file.
This commit also changes how private keys and certificates were
handled with the BLOB scheme. Previously only the first certificate
or first private key was included in the property data, while now
the entire file is encoded in the data. This is intended to fix
cases where multiple private keys or certificates are present in
a PEM file. It also allows clients to push certificate data to
NetworkManager for storage in system settings locations, which was
not as flexible before when only part of the certificate or key
was sent as the data.
The old function took a string value, which wasn't really correct as
the property type is a GHashTable of string:string. For whatever
reason this is how nm-applet passed VPN secrets back to NM in the return
from the GetSecrets() D-Bus call. This was probably easier or
something but it was a special case that's magic and quite unclear.
Since we use nm_connection_update_secrets() more these days, and we
depend on the GValue types we pass into it matching the property
types of the setting property the secret is for, we need to fix that
up for VPN connections. But keep the old code for backwards
compatibility.
In the future secret agents should pass back VPN secrets in the same
form as the VPN setting specifies them for the "secrets" property:
a GHashTable of string:string. But the old mechanism of just dumping
the key/value pairs into the returned VPN hash as string:string will
still work.
The first-level hash table key should be the setting name itself,
not the GType name of the setting's GObject. There's probably a
better way to do this to reduce that confusion.
Simplifies code internally, and makes it easier for clients as well in
some cases where they want to control what ends up in the resulting
hash and what does not.
APNs can only contain alphanumeric characters, '.', and '-'. To be
helpful we strip spaces off before setting the APN internally so that
previously (and incorrectly) valid APNs don't cause the whole
connection to fail validation and thus disappear. The only case seen
in the wild was a Pelephone IL APN which erroneously had a trailing
space in the mobile broadband provider database. Bad characters
cause the connection to fail with vague error messages about being
unable to activate the PDP context during PPP negotiation.
Ensure it still works correctly if something tries to set the
'addresses' property using the old GType. Also make sure that
the various IP6 address comparison operations and string conversion
functions handle the gateway.
Two errors here; first, need_secrets_tls() was not updated correctly
for the certificate paths changes that landed recently, and would
have incorrectly returned "no secrets required" for the PATH scheme.
Second, an incorrect strcmp() comparison in need_secrets_phase2()
meant that the wrong TTLS phase2 method would get asked if it
required secrets.
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.
0.7 requires dbus 1.1 or greater (for system bus activation), so make that
explicit, and remove compat code for D-Bus 0.6 and earlier. Consolidate
the various glib pkgconfig checks into one, since most anything will require
gthread, glib, and gobject anyway. Fixup the docs makefile to be more
automake-compatible and let 'make clean' actually work correctly when
docs are built.
This caused the 'autoconnect' property of NMSettingConnection to not
get updated in some cases (as when a system setting plugin noticed a
change to autoconnect=true and emitted the Updated signal, which wouldn't
contain the new value). Add a testcase for setting default values too.
