keyfile should become our main import/export format. It is desirable,
that a keyfile can contain every aspect of a connection.
For blob certificates, the writer in core daemon would always write
them to a file and convert the scheme to path.
This behavior is not great for a (hyptetical) `nmcli connection export`
command because it would have to export them somehow outside of keyfile,
e.g. by writing them to temporary files.
Instead, if the write handler does not handle a certificate, use a
default implementation in nm_keyfile_write() which adds the blob inside
the keyfile.
Interestingly, keyfile reader already supported reading certificate
blobs. But this legacy format accepts the blob as arbitrary
binary without marking the format and without scheme prefix.
Instead of writing the binary data directly, write it with a new
uri scheme "data:;base64," and encode it in base64.
Also go through some lengths to make sure that whatever path
keyfile plugin writes, can be read back again. That is, because
keyfile writer preferably writes relative paths without prefix.
Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate
the detection of pathnames without file:// prefix and use it to
check whether the path name must be fully qualified.
In _nm_setting_new_from_dbus(), verify that the properties have the
right types, and return an error if not. (In particular, don't crash
if someone tries to assign a GBytes-valued property a non-'ay' value.)
For IPv4 addresses, the binary representation is in network-order,
contrary to host-order. It's better to choose addresses for testing
that are differently on big and little endian systems.
Error: CHECKED_RETURN (CWE-252): [#def12]
NetworkManager-0.9.11.0/libnm-core/tests/test-general.c:348: check_return: Calling "nm_setting_verify" without checking return value (as is done elsewhere 37 out of 45 times).
...
Before we would just call verify() and only return valid connections
without attempting to fix them.
It is better to use normalize(), because that function is especially there to
accept and repair deprecated configurations that would no longer verify().
This changes behavior in the way that the function now accepts connections
that would have been rejected before.
Since commit b88715e05b normalize() also
adds a missing UUID. Hence this also affects the DBUS method 'AddConnection'
in that it now accepts connections without UUID. Previously, clients were
required to set a UUID for the new connection, now NM core can create a random
one if no UUID is set.
https://bugzilla.gnome.org/show_bug.cgi?id=740813
There are different types (variants) of UUIDs defined.
Especially variants 3 and 5 are name based variants (rfc4122).
The way we create our UUIDs in nm_utils_uuid_generate_from_string()
however does not create them according to RFC and does not set
the flags to indicate the variant.
Modify the signature of nm_utils_uuid_generate_from_string() to accept
a "uuid_type" argument, so that we later can add other algorithms without
breaking API.
In general, we shouldn't end up with an unencrypted copy of a
certificate key anyway, so this function ought to be unnecessary (or
at least, not broadly useful enough to be in the public API).
nm-applet's GConf migration tool needs it, but that will eventually go
away, and until then it can just use libnm-util.
crypto_md5_hash() only has two users:
(a) crypto_make_des_aes_key()
(b) nm_utils_uuid_generate_from_string()
For (b) it is just a complicated way to compute the MD5 hash. The
restrictions on salt and password don't matter. Actually they
are harmful because we cannot compute the MD5 hash of the empty
word.
For (a), the caller should make sure to pass whatever restrictions
he wants to enforce on the data.
For example, it is counterintuitive, that crypto_md5_hash() would
require @salt_len, enforce it to be at least 8 bytes, and then just
use the first 8 bytes. If the caller (a) wants that behavior, he
should make sure that he passes in 8 bytes.
Likewise for the empty word. If the caller does not want to compute
the hash of empty passwords, he must not hash them.
Indeed, all of this was enforced by assertions, any caller already
did the right thing.
Rather than requiring crypto_init() to have been called beforehand,
just have every method that depends on it call it itself.
This required adding a GError argument to crypto_is_pkcs12_data(),
which in turn required a few other changes elsewhere.
We were always using the gateway field of the first address in
ipv4.addresses / ipv6.addresses to set the gateway, but to be
compatible with old behavior, we should actually be using the first
non-0 gateway field (if the first one is 0).
Add nm-utils methods to check if a file is a certificate or private
key file.
nm-applet currently has its own internal versions of these, but they
ended up having to duplicate a bunch of logic that we already have in
crypto.c.
Update crypto_verify_private_key() and
crypto_verify_private_key_data() to indicate whether the key was
encrypted or not.
Rename crypto_decrypt_private_key() and
crypto_decrypt_private_key_data() to
crypto_decrypt_openssl_private_key*, since that's the only private key
format they deal with, and the old names made them sound more generic
than they were. Also, update the openssl private key parsing code to
recognize unencrypted private keys as well. (Previously we accepted
unencrypted PKCS#8 keys, but not unencrypted openssl-style keys.)
Fixes testing on 32-bit arches:
/core/general/test_setting_compare_timestamp:
(./test-general:29331): GLib-GObject-WARNING **: g_object_set_valist: object class `NMSettingConnection' has no property named `$?\xff\xff\x89t$0\x89|$4\xe8\u001c\x98\xff\xff\x85\xc0tM\x83\xf8\xfft3\x8dT$(\xc7D$\u0008'
/bin/sh: line 5: 29331 Trace/breakpoint trap ${dir}$tst
FAIL: test-general
Fixes: 093a3c88d0
Although libnm filters out properties received from the daemon that it
doesn't understand, there may be other clients that do not. In
particular, a client might call GetSettings() on a connection, update
the ipv4.addresses property in the returned dictionary, and then pass
the dictionary to Update(). In that case, the updated dictionary would
contain ipv4.address-data, but it would not reflect the changes the
client intended to make.
Fix this by changing the daemon side to prefer the legacy properties
to the new ones if both are set, and changing the client side to not
send the legacy properties (since we don't support new clients talking
to old servers anyway).
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Make the type return GBytes since most in-tree users want that.
Allow the function to accept many more formats as valid hex, including
bytes delimited by ':' and a leading '0x'.
Add AddressData and RouteData properties to NMSettingIPConfig and
NMIP[46]Config. These are like the existing "addresses" and "routes"
properties, but using strings and containing additional attributes,
like NMIPAddress and NMIPRoute.
This only affects the D-Bus representations; there are no API changes
to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the
additional information is just added to the existing 'addresses' and
'routes' properties.
NMSettingIP4Config and NMSettingIP6Config now always generate both
old-style data ('addresses', 'address-labels', 'routes') and new-style
data ('address-data', 'gateway', 'route-data') when serializing to
D-Bus, for backward compatibility. When deserializing, they will fill
in the 'addresses' and 'routes' properties from the new-style data if
it is present (ignoring the old-style data), or from the old-style
data if the new-style isn't present.
The daemon-side NMIP4Config and NMIP6Config always emit changes for
both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The
libnm-side classes initially listen for changes on both properties,
but start ignoring the 'Addresses' and 'Routes' properties once they
know the daemon is also providing 'AddressData' and 'RouteData'.
The gateway is a global property of the IPv4/IPv6 configuration, not
an attribute of any particular address. So represent it as such in the
API; remove the gateway from NMIPAddress, and add it to
NMSettingIPConfig.
Behind the scenes, the gateway is still serialized along with the
first address in NMSettingIPConfig:addresses, and is deserialized from
that if the settings dictionary doesn't contain a 'gateway' key.
Adjust nmcli's interactive mode to prompt for IP addresses and gateway
separately. (Patch partly from Jirka Klimeš.)
Split a base NMSettingIPConfig class out of NMSettingIP4Config and
NMSettingIP6Config, and update things accordingly.
Further simplifications of now-redundant IPv4-vs-IPv6 code are
possible, and should happen in the future.
Add key-value attributes to NMIPAddress and NMIPRoute, and use them to
store IPv4 address labels. Demote NMSettingIP4Config:address-labels to
a D-Bus-only property, and arrange for :addresses setter to read the
labels out of that property when creating the addresses.
Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
nm_setting_verify() took a GSList of other NMSettings, but really it
would just be simpler all around to pass the NMConnection instead...
This means that several formerly NMSetting-branded functions that
operated on lists-of-settings now get replaced with
NMConnection-branded functions instead.
Add nm-core-types.h, typedefing all of the GObject types in
libnm-core; this is needed so that nm-setting.h can reference
NMConnection in addition to nm-connection.h referencing NMSetting.
Removing the cross-includes from the various headers causes lots of
fallout elsewhere. (In particular, nm-utils.h used to include
nm-connection.h, which included every setting header, so any file that
included nm-utils.h automatically got most of the rest of libnm-core
without needing to pay attention to specifics.) Fix this up by
including nm-core-internal.h from those files that are now missing
includes.
