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.
These headers are not entirely private to libnm-core as they are also
used by keyfile plugin. Merge them to a new header file
nm-keyfile-internal.h so that the name makes the internal nature of the
header more apparent.
This is the first step to move keyfile to libnm. For now, only
copy the files to make later changes nicer in git-history.
/bin/cp src/settings/plugins/keyfile/reader.c libnm-core/nm-keyfile-reader.c
/bin/cp src/settings/plugins/keyfile/reader.h libnm-core/nm-keyfile-reader.h
/bin/cp src/settings/plugins/keyfile/utils.c libnm-core/nm-keyfile-utils.c
/bin/cp src/settings/plugins/keyfile/utils.h libnm-core/nm-keyfile-utils.h
/bin/cp src/settings/plugins/keyfile/writer.c libnm-core/nm-keyfile-writer.c
/bin/cp src/settings/plugins/keyfile/writer.h libnm-core/nm-keyfile-writer.h
When setting the certificate glib properties directly,
we raise a g_warning() when the binary data is invalid.
But since the caller has no access to the validation function,
he cannot easily check whether his action will result
in a warning. Add nm_setting_802_1x_check_cert_scheme() for
that.
A valid blob cannot start with "file://", otherwise it would
break the implementation of the certificate properties in
NMSetting8021x. Simply reject every blob in nm_setting_802_1x_set_ca_cert()
et al. that is not valid according to get_cert_scheme().
get_cert_scheme() would return PATH scheme for binary data that
later will be rejected by verify_cert(). Even worse, get_cert_scheme()
would not check whether the path is NUL terminated, hence the following
can crash for an invalid connection:
if (nm_setting_802_1x_get_ca_cert_scheme (s_8021x) == NM_SETTING_802_1X_CK_SCHEME_PATH)
g_print ("path: %s", nm_setting_802_1x_get_ca_cert_path (s_8021x))
Combine the two functions so that already get_cert_scheme() does
the same validation as verify_cert().
Also change behavior and be more strict about invalid paths:
- Now, the value is considered a PATH candidate if it starts with "file://",
(sans NUL character).
A change is that before, the "file://" (without NUL) would have
been treated as BLOB, now it is an invalid PATH (UNKNOWN).
- If the binary starts with "file://" it is considered as PATH but it
is only valid, if all the fllowing is true:
(a) the last character must be NUL.
(b) there is no other intermediate NUL character.
Before, an intermediate NUL character would have been accepted
and the remainder would be ignored.
(c) there is at least one non-NUL character after "file://".
(d) the string must be fully valid utf8.
The conditions (b) and (c) are new and some invalid(?) paths
might no longer validate.
Checking (d) moved from verify_cert() to get_cert_scheme().
As set_cert_prop_helper() already called verify_cert(), this
causes no additional change beyond (b).
The newly added bond mode APIs in nm-utils will be new in 1.2, so mark
them as such in the headers and docs, move them to a new section in
libnm.ver.
Since we're adding the new section to libnm.ver, this also seems like
a good time to bump the soname.
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.)
libnm-util's nm_setting_new_from_hash() needed to call
g_type_class_ref(setting_type) to ensure that the class had been
initialized by the time we fetched its properties. But in libnm-core's
version, we create the setting object before fetching the list of
properties, so we know the class will already have been initialized by
that point.
Use descriptive string value as preferred bond mode representation.
Numeric modes still verify but with NM_SETTING_VERIFY_NORMALIZABLE,
suggesting a normalization action.
https://bugzilla.redhat.com/show_bug.cgi?id=1171009
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.
In the 'configure.ac' script we already detect the git commit id
for the current source version. When creating a tarball, it is also
included inside the generated 'configure' script.
Add the commit id as a static string to nm-utils.c. That way, having
a build of libnm.so or NetworkManager, you can quickly find the
corresponding git commit:
strings src/NetworkManager | grep NM_GIT_SHA
Note that this only works after a new `autogen.sh` run. Only rebuilding
is not enough. Hence, you must rebuild all to ensure that the correct
commit id is embedded.
https://bugzilla.gnome.org/show_bug.cgi?id=741651
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).
...
