It happens when one selected private key, but didn't provide the password yet
in nm-connection-editor.
(nm-connection-editor:11080): libnm-util-CRITICAL **: crypto_md5_hash: assertion `password_len > 0' failed
This results in some nice coloring. Only move the tests that are called
without arguments from check-local to TESTS.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This is intended to contain utility functions for tests. It will
be header only (containing inline functions).
Signed-off-by: Thomas Haller <thaller@redhat.com>
Commit 240c92ddb5 added an assert
to check that the input netmask is valid. Revert that commit for
the most part, some changes to the test function are not reverted.
We don't want to assert for a valid netmask, because it's
common to read the netmask from (untrusted) user input, so we
don't want to assert against it.
The caller *could* validate the netmask from untrusted sources, but
with the assert in place it cannot validate it in the most obvious way:
prefix = nm_utils_ip4_netmask_to_prefix (netmask);
if (netmask != nm_utils_ip4_prefix_to_netmask (prefix))
goto fail;
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_setting_wired_remove_mac_blacklist_item_by_value()
Also add missing function nm_setting_wired_clear_mac_blacklist_items() and notify
about mac-address-blacklist changes.
Add versioned NM_DEPRECATED_IN_* and NM_AVAILABLE_IN_* macros, and tag
new/deprecated functions accordingly. (All currently-deprecated
functions are assumed to have been deprecated in 0.9.10.)
Add NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED macros which
can be set to determine which versions will cause warnings.
With the current settings, external consumers of the
libnm-util/libnm-glib APIs will have MIN_REQUIRED and MAX_ALLOWED both
set to NM_VERSION_0_9_8 by default, meaning they will get warnings
about functions added in 0.9.10. NM internally sets
NM_VERSION_MAX_ALLOWED to NM_VERSION_NEXT_STABLE to ensure that it is
always allowed to use all APIs.
Given an IPv4 address and prefix for a shared config, figure out
the DHCP address range automatically. To keep things simple we
allow a max of 252 addresses (not including network address,
broadcast address, and the hotspot) no matter what prefix you use,
so if the address is 10.0.10.1, you still only get a range of
10.0.10.2 -> 10.0.10.254.
But we also leave some addresses available above the host address
for static stuff, like we did before. This is done on a sliding
scale from 0 to 8 addresses, where about 1/10th the number of
available addresses are reserved.
https://bugzilla.gnome.org/show_bug.cgi?id=675973
This changes behaviour of nm_connection_update_secrets() in that it will
now return %TRUE, if there are no secrets to be cleared. Seems more
correct, to return success if there is nothing to do.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Often, nm_connection_clear_secrets does have no consequences, because
there is nothing to be cleared. Only raise a signal, if something
actually changed.
Signed-off-by: Thomas Haller <thaller@redhat.com>
- use a more efficient implementation for prefix_to_netmask
- fix netmask_to_prefix to behave consistently in case of
invalid netmask
- remove unused duplicated functions from NetworkManagerUtils.c
- add test functions
Based-on-patch-by: Pavel Šimerda <psimerda@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Related: https://bugzilla.gnome.org/show_bug.cgi?id=721771
