Without marking the enumeration as flags, the types will be "enumeration"
instead of "bitfield". And python raises ValueError exception.
Example:
from gi.repository import NMClient, NetworkManager
client = NMClient.Client.new()
for dev in client.get_devices():
if dev.get_device_type() == NetworkManager.DeviceType.WIFI:
for ap in dev.get_access_points():
ap.get_rsn_flags()
raises "ValueError: invalid enum value: 648"
https://bugzilla.redhat.com/show_bug.cgi?id=1255436
Port remaining bits to gdbus and remove stray dbus-glib references
Drop the dbus-glib version check from configure, since nothing depends
on new dbus-glib any more.
Move nm-dbus-glib-types.h and nm-gvaluearray-compat.h from include/ to
libnm-util/ since they are now only used by libnm-util and libnm-glib.
The localization headers are now included via "nm-default.h".
Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
Add a bunch of compat defines to nm-vpn-plugin-ui-interface.h, to make
it easier to compile the same code against libnm-glib's
NMVpnPluginUiInterface and libnm's NMVpnEditorPlugin.
https://bugzilla.gnome.org/show_bug.cgi?id=752500
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
g_convert_with_fallback() will fail if the SSID contains characters that
are not legal in the source encoding, which, if $LANG is not set, will
be ASCII. If this happens, replace all non-ASCII and non-printable
characters with '?'. It is possible that nm_utils_ssid_to_utf8() will
now return an empty string (e.g., the source string is actually
big-endian UTF-16 and g_strcanon() stops on the first byte), but it will
not return NULL.
https://bugzilla.redhat.com/show_bug.cgi?id=1243078
It yields completely unpredictable results on Ubuntu 12.04 (the global variable
successfully comparing to NULL despite demonstrably not NULL). Possibly a
toolchain bug.
We already have "nm-utils*.h" and "NetworkManagerUtils.h" headers. Rename
"include/nm-utils-internal.h" to "nm-macros-internal.h". I think that
name is better, because this file is header-only, internal, and
repository-wide.
Also, it will never contain non-header-only declarations because
there is no backing object file under "include/".
It will only contain macros and inline functions.
For existing devices, depending on the order that netlink sends interfaces to
us, the parent may be found after the VLAN interface and not be available when
the VLAN interface is constructed. Instead of failing construction, when a
NMDeviceVlan has no parent keep it unavailable for activation. Then have
the Manager notify existing devices when a new device is found, and let
NMDeviceVlan find the parent later and become available via that mechanism.
This doesn't apply to VLANs created by NM itself, because the kernel requires
a parent ifindex when creating a VLAN device. Thus this fix only applies to
VLANs created outside NetworkManager, or existing when NM starts up.
Even Fedora is no longer shipping the WiMAX SDK, so it's likely we'll
eventually accidentally break some of the code in src/devices/wimax/
(if we haven't already). Discussion on the list showed a consensus for
dropping support for WiMAX.
So, remove the SDK checks from configure.ac, remove the WiMAX device
plugin and associated manager support, and deprecate all the APIs.
For compatibility reasons, it is still possible to create and save
WiMAX connections, to toggle the software WiMAX rfkill state, and to
change the "WIMAX" log level, although none of these have any effect,
since no NMDeviceWimax will ever be created.
nmcli was only compiling in support for most WiMAX operations when NM
as a whole was built with WiMAX support, so that code has been removed
now as well. (It is still possible to use nmcli to create and edit
WiMAX connections, but those connections will never be activatable.)
Add new capabilities CAP_FREQ_2GHZ and CAP_FREQ_5GHZ to indicate the
frequency bands supported by a Wifi device.
Add also CAP_FREQ_VALID, which is set when the values of the other 2
capabilities are available.
Original patch by Dan Williams <dcbw@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=723295
We must never fail verification of a connection based on a password
because the password is re-requested during activation.
Otherwise, if the user enters an invalid password for a (previously)
valid connection, the connection becomes invalid. NetworkManager does
not expect or handle that requesting password can make a connection
invalid.
Invalid passwords should be treated as wrong passwords. Only a UI
(such as nm-connection-editor or nmcli) should validate passwords
against a certain scheme.
Note that there is need_secrets() which on the contrary must check for
valid passwords.
Error scenario:
Connect to a WEP Wi-Fi, via `nmcli device wifi connect SSID`. The
generated connection has wep-key-type=0 (UNKNOWN) and wep-key-flags=0.
When trying to connect, NM will ask for secrets and set the wep-key0
field. After that, verification can fail (e.g. if the password is longer
then 64 chars).
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).
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: 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.
We now also use a similar function in VPN plugins. It makes
sense to provide a generic implementation in libnm.
Signed-off-by: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=740783
A failure to g_return_*() prints a critical warning which contains
G_STRFUNC. Depending on the compiler this contains only the function
name or the entire signature.
Relax the assertion pattern to check the function name.
