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).
...
Error: RESOURCE_LEAK (CWE-772): [#def10]
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:225: alloc_fn: Storage is returned from allocation function "priority_map_new_from_str".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:154:4: alloc_fn: Storage is returned from allocation function "g_malloc0".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:154:4: var_assign: Assigning: "p" = "g_malloc0(8UL)".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:164:2: return_alloc: Returning allocated memory "p".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:225: var_assign: Assigning: "item" = storage returned from "priority_map_new_from_str(map, str)".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:226: leaked_storage: Variable "item" going out of scope leaks the storage it points to.
Error: RESOURCE_LEAK (CWE-772): [#def11]
NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2056: alloc_fn: Storage is returned from allocation function "crypto_make_des_aes_key".
NetworkManager-0.9.11.0/libnm-core/crypto.c:405:2: alloc_fn: Storage is returned from allocation function "g_malloc0".
NetworkManager-0.9.11.0/libnm-core/crypto.c:405:2: var_assign: Assigning: "key" = "g_malloc0(digest_len + 1U)".
NetworkManager-0.9.11.0/libnm-core/crypto.c:407:2: noescape: Resource "key" is not freed or pointed-to in function "crypto_md5_hash".
NetworkManager-0.9.11.0/libnm-core/crypto.c:769:24: noescape: "crypto_md5_hash(char const *, gssize, char const *, gssize, char *, gsize)" does not free or save its pointer parameter "buffer".
NetworkManager-0.9.11.0/libnm-core/crypto.c:415:2: return_alloc: Returning allocated memory "key".
NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2056: var_assign: Assigning: "key" = storage returned from "crypto_make_des_aes_key("DES-EDE3-CBC", &salt[0], salt_len, in_password, &key_len, NULL)".
NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2057: leaked_storage: Variable "key" going out of scope leaks the storage it points to.
VPN connections always return true for nm_connection_need_secrets(), but the
documented behavior of GetSecrets() is just to return any secrets we have
(otherwise nmcli c --show-secrets would not be useful for VPN connections).
Motivated by avoiding compiler warning with -O2 -Wstrict-overflow (gcc-4.8.3):
make[4]: Entering directory `./NetworkManager/libnm-core'
CC nm-utils.lo
../libnm-core/nm-utils.c: In function 'nm_utils_hwaddr_valid':
../libnm-core/nm-utils.c:2725:14: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (length == 0 || length > NM_UTILS_HWADDR_LEN_MAX)
^
../libnm-core/nm-utils.c: In function 'nm_utils_hwaddr_canonical':
../libnm-core/nm-utils.c:2755:14: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (length == 0 || length > NM_UTILS_HWADDR_LEN_MAX)
^
https://bugzilla.gnome.org/show_bug.cgi?id=741168
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
crypto_md5_sum() already accepts two separate strings: salt and password.
No need to allocate a temporary buffer. Just pass @ns_uuid and @s
separately.
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).
NMIPRoute is used by NMSettingIPConfig, but also
NMIPConfig. In the former case, default routes are (still)
disallowed. But in the NMIPConfig use-case, it can make sense
to expose default routes as NMIPRoute instances.
Relax the restriction on the NMIPRoute API to allow this
future change.
No code actually supports having NMIPRoute instances with
prefix length zero (default routes). Up to now, all such uses
would be a bug.
https://bugzilla.gnome.org/show_bug.cgi?id=739969
Signed-off-by: Thomas Haller <thaller@redhat.com>
/libnm/crypto/PKCS#8: OK
/libnm/crypto/cert/pem: ==16241== Conditional jump or move depends on uninitialised value(s)
==16241== at 0x121967: crypto_load_and_verify_certificate (crypto.c:605)
==16241== by 0x12512E: nm_utils_file_is_certificate (nm-utils.c:2279)
==16241== by 0x1201F1: test_cert (test-crypto.c:113)
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.)
