and use it in 'allowed-bands' property installation.
The macro NM_SETTING_GSM_BANDS_MAX also allows libnm-util users to check
if bands are valid (before setting them).
nm_setting_to_hash() would return NULL if the setting had entirely
default values, but this effectively meant that you could never have a
connection whose "connection type" setting (eg, NMSettingWired) had
all default values. (This ended up not usually being a problem in
practice because most such settings had at least one property with a
mandatory string value where the GObject property had a default value
of NULL.)
However, NMSettingGeneric will have no properties, so it would always
get stripped out when converting to a hash, invalidating the
connection. Fix that.
When 'connection' and 'new_connection' arguments are the same object make the
function no-op and simply return true. Otherwise 'connection's settings are
removed, making it invalid.
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
The various need_secrets() implementation do allocate a fresh GPtrArray, but
add static strings to them without dup'ing. Thus callers must _not_ free the
array elements, only the array itself. Adjust documentation and annotations
accordingly.
Also adjust the corresponding comment in the goi-list-connections.py example.
https://bugzilla.gnome.org/show_bug.cgi?id=698175
Convenience function to replace settings in one conneciton with settings
from another, without having to go through the nm_connection_to_hash()
steps, which are just inefficient and kinda pointless.
We want to free the element data, then remove the element from the
list. Instead the code freed the element data, then treated the
element data pointer as a GSList link, which is completely wrong.
to match other property removal functions, like nm_setting_bond_remove_option()
or nm_setting_wired_remove_s390_option().
Note:
This is an API change, make sure to bump soname when releasing libnm-util.
The setting names used when inserting a setting into the hash
table are const since they are derived from GObject internals,
so there's no need to strdup them.
GLib-GObject-WARNING **: g_object_get_property: object class `NMSetting8021x' has no property named `pin'
GLib-GObject-WARNING **: g_object_get_property: object class `NMSetting8021x' has no property named `pin-flags'
libnm-glib's public headers include headers from libnm-util. While it
does work to just $(pkg-config --cflags --libs libnm-glib), this is
only because libnm-glib has a requires on NetworkManager which happens
to use the same include directory as libnm-util.
The correct dependency chain is thus:
libnm-glib -> libnm-util -> NetworkManager
Signed-off-by: Colin Walters <walters@verbum.org>
==7347== 1,201 bytes in 1 blocks are definitely lost in loss record 5,016 of 5,107
==7347== at 0x4A06B0F: calloc (vg_replace_malloc.c:593)
==7347== by 0x39B90548E6: g_malloc0 (gmem.c:189)
==7347== by 0x39B9026F8D: g_base64_decode (gbase64.c:407)
==7347== by 0x4C51CA1: parse_old_openssl_key_file (crypto.c:227)
==7347== by 0x4C51EC3: crypto_decrypt_private_key_data (crypto.c:497)
==7347== by 0x4C529BE: crypto_verify_private_key_data (crypto.c:706)
==7347== by 0x4C52B7B: crypto_verify_private_key (crypto.c:735)
==7347== by 0x4C5CCC5: nm_setting_802_1x_set_private_key (nm-setting-8021x.c:1633)
==7347== by 0xC8F64D4: eap_tls_reader (reader.c:2270)
==7347== by 0xC8F4886: fill_8021x (reader.c:2704)
==7347== by 0xC8F8311: wireless_connection_from_ifcfg (reader.c:2825)
==7347== by 0xC8FAFD2: connection_from_file (reader.c:4303)
==23089== 342 bytes in 38 blocks are definitely lost in loss record 4,870 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B906A4BB: g_strdup (gstrfuncs.c:356)
==23089== by 0x31FC02DA90: set_property (nm-setting-pppoe.c:220)
==23089== by 0x39B9819972: g_object_set_property (gobject.c:1352)
==23089== by 0x31FC01A9A7: nm_setting_enumerate_values (nm-setting.c:589)
==23089== by 0x31FC01AA81: nm_setting_duplicate (nm-setting.c:264)
==23089== by 0x31FC01633B: duplicate_cb (nm-connection.c:1182)
==23089== by 0x39B903F8DF: g_hash_table_foreach (ghash.c:1524)
==23089== by 0x31FC01756C: nm_connection_duplicate (nm-connection.c:1203)
==23089== by 0x4A7BE3: get_settings_auth_cb (nm-settings-connection.c:1062)
==23089== by 0x4A5624: auth_start (nm-settings-connection.c:1008)
'str' was not freed anywhere.
==23089== 2,072 (24 direct, 2,048 indirect) bytes in 1 blocks are definitely lost in loss record 5,063 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B906C7FA: g_string_sized_new (gstring.c:121)
==23089== by 0x39B906CE75: g_string_new_len (gstring.c:186)
==23089== by 0x31FC0149CE: parse_old_openssl_key_file (crypto.c:150)
==23089== by 0x31FC014E33: crypto_decrypt_private_key_data (crypto.c:494)
==23089== by 0x31FC01592E: crypto_verify_private_key_data (crypto.c:703)
==23089== by 0x31FC015AEB: crypto_verify_private_key (crypto.c:732)
==23089== by 0x31FC0200E5: nm_setting_802_1x_set_private_key (nm-setting-8021x.c:1640)
==23089== by 0xC694304: eap_tls_reader (reader.c:2280)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
If the certificate's format was valid, but we're asked to refer to it by
paths instead of using the raw data, 'data' would be leaked.
==23089== 8,232 (40 direct, 8,192 indirect) bytes in 1 blocks are definitely lost in loss record 5,109 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B9024539: g_array_sized_new (garray.c:195)
==23089== by 0x31FC0146EA: file_to_g_byte_array (crypto.c:319)
==23089== by 0x31FC01543B: crypto_load_and_verify_certificate (crypto.c:606)
==23089== by 0x31FC01ED26: nm_setting_802_1x_set_client_cert (nm-setting-8021x.c:819)
==23089== by 0xC6944A4: eap_tls_reader (reader.c:2316)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
==23089== by 0xC696151: wireless_connection_from_ifcfg (reader.c:2832)
==23089== by 0xC698E3A: connection_from_file (reader.c:4316)
==23089== by 0xC69135C: nm_ifcfg_connection_new (nm-ifcfg-connection.c:119)
==23089==
==23089== 8,352 (160 direct, 8,192 indirect) bytes in 4 blocks are definitely lost in loss record 5,110 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B9024539: g_array_sized_new (garray.c:195)
==23089== by 0x31FC0146EA: file_to_g_byte_array (crypto.c:319)
==23089== by 0x31FC01543B: crypto_load_and_verify_certificate (crypto.c:606)
==23089== by 0x31FC01E5E6: nm_setting_802_1x_set_ca_cert (nm-setting-8021x.c:538)
==23089== by 0xC694DD8: eap_peap_reader (reader.c:2358)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
==23089== by 0xC696151: wireless_connection_from_ifcfg (reader.c:2832)
==23089== by 0xC698E3A: connection_from_file (reader.c:4316)
==23089== by 0xC69135C: nm_ifcfg_connection_new (nm-ifcfg-connection.c:119)
==23089== 7,293 (1,248 direct, 6,045 indirect) bytes in 39 blocks are definitely lost in loss record 5,100 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B9024E90: g_ptr_array_sized_new (garray.c:884)
==23089== by 0x31FB81B3FC: ptrarray_copy (dbus-gvalue-utils.c:1047)
==23089== by 0x31FB81845C: proxy_value_copy (dbus-gtype-specialized.c:446)
==23089== by 0x39B980F51E: g_boxed_copy (gboxed.c:359)
==23089== by 0x31FC03134C: set_property (nm-setting-wired.c:619)
==23089== by 0x39B9819972: g_object_set_property (gobject.c:1352)
==23089== by 0x31FC01A9A7: nm_setting_enumerate_values (nm-setting.c:589)
==23089== by 0x31FC01AA81: nm_setting_duplicate (nm-setting.c:264)
==23089== by 0x31FC01633B: duplicate_cb (nm-connection.c:1182)
GValueArray is deprecated. Unfortunately, it's part of our API right now,
so we have to keep it around for a while. But since it's deprecated, and
we want to know about *other* deprecations, we have to suppress deprecations
about GValueArray. Unfortunately using macros to do that (eg in
nm-gvaluearray-compat.h) exposes some compiler bugs due to the combination
of parentheses/braces and #pragma from G_GNUC_BEGIN_IGNORE_DEPRECATIONS,
resulting in warnings like:
nm-utils.c:920:9: error: expected expression before ‘#pragma’
Work around this by not trying to stuff what's now a macro (eg
g_value_array_get_nth) into what's already a macro (G_VALUE_TYPE).
There's probably a better way to do this...
Avoid warnings about GValueArray being deprecated by adding macros
that wrap G_GNUC_BEGIN_IGNORE_DEPRECATIONS /
G_GNUC_END_IGNORE_DEPRECATIONS around the GValueArray calls.
