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.
The function was changed to return NULL instead of empty hash by commit
ad56cfa914. Later, the condition had to be
relaxed for NMSettingGeneric (commit 4d32618264).
Unforfunately, it shows up that there are other use cases that require
presence of a setting (that might have all properties default), such as
NMSettingBridgePort for bridge slave connections.
libnm already behaves this way, since commit
6325c596c0.
https://bugzilla.gnome.org/show_bug.cgi?id=740681
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
docs/api/settings-spec.xml was accidentally not getting disted,
because gtk-doc.make explicitly removes all DISTCLEANFILES from
distdir. However, it doesn't actually make sense for the settings docs
files to be in DISTCLEANFILES anyway; they were put there rather than
CLEANFILES (IIRC) so that "make clean" in a tarball build wouldn't
delete them and break things. But the right fix is to just make them
only be in CLEANFILES when BUILD_SETTING_DOCS is true, and not ever
get deleted otherwise.
Also adjust the build rules to ensure that the generated docs don't
get rebuilt in tarball builds, since that can cause problems when
building from a read-only source tree, etc.
Meanwhile, in an unrelated but also fatal bug, configure.ac's check
for if the generated docs were already present never got updated for
the cli/src -> clients/cli move, and so even if we had been disting
settings-spec.xml, configure would still think that the tarball didn't
have all of the generated docs in it, so SETTING_DOCS_AVAILABLE would
be set false and none of the generated docs would get used.
https://bugzilla.gnome.org/show_bug.cgi?id=740035
Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _()
will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than
"gettext (string)" (which will use the program's default domain, which
works fine for programs in the NetworkManager tree, but not for
external users). Likewise, we need to call bindtextdomain() so that
gettext can find the translations if the library is installed in a
different prefix from the program using it (and
bind_textdomain_codeset(), so it will know the translations are in
UTF-8 even if the locale isn't).
(The fact that no one noticed this was broken before is because the
libraries didn't really start returning useful translated strings much
until 0.9.10, and none of the out-of-tree clients have been updated to
actually show those strings to users yet.)
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
The plugin can indicate that this connection can persist across link
changes and other connectivity dropouts by passing this option
back in the SetConfig() calls.
This property will indicate that the user wishes the VPN connection
to stay active until explicitly disconnected, even across link changes
or other interruptions.
Previously, nm_setting_diff() (and thus nm_connection_diff()), returned
only properties that are different AND not set to the default value.
However, if the opposite setting 'B' was missing, it would always
include all properties from 'A', even the default ones.
This behaviour was asymetric. Add two new compare flags
@NM_SETTING_COMPARE_FLAG_DIFF_RESULT_WITH_DEFAULT and
@NM_SETTING_COMPARE_FLAG_DIFF_RESULT_NO_DEFAULT to control the
behaviour of whether to include default properties.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When secret providers return the connection hash in GetSecrets(),
this hash should only contain secrets. However, some providers also
return non-secret properties.
for_each_secret() iterated over all entries of the @secrets hash
and triggered the assertion in nm_setting_get_secret_flags() (see
below).
NM should not assert against user provided input. Change
nm_setting_get_secret_flags() to silently return FALSE, if the property
is not a secret.
Indeed, handling of secrets is very different for NMSettingVpn and
others. Hence nm_setting_get_secret_flags() has only an inconsistent
behavior and we have to fix all call sites to do the right thing
(depending on whether we have a VPN setting or not).
Now for_each_secret() checks whether the property is a secret
without hitting the assertion. Adjust all other calls of
nm_setting_get_secret_flags(), to anticipate non-secret flags and
assert/warn where appropriate.
Also, agent_secrets_done_cb() clears now all non-secrets properties
from the hash, using the new argument @remove_non_secrets when calling
for_each_secret().
#0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0
#1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0
#2 0x00007fa4b0c1c156 in get_secret_flags (setting=0x1e3ac60, secret_name=0x1ea9180 "security", verify_secret=1, out_flags=0x7fff7507857c, error=0x0) at nm-setting.c:1091
#3 0x00007fa4b0c1c2b2 in nm_setting_get_secret_flags (setting=0x1e3ac60, secret_name=0x1ea9180 "security", out_flags=0x7fff7507857c, error=0x0) at nm-setting.c:1124
#4 0x0000000000463d03 in for_each_secret (connection=0x1deb2f0, secrets=0x1e9f860, callback=0x464f1b <has_system_owned_secrets>, callback_data=0x7fff7507865c) at settings/nm-settings-connection.c:203
#5 0x000000000046525f in agent_secrets_done_cb (manager=0x1dddf50, call_id=1, agent_dbus_owner=0x1ddb9e0 ":1.39", agent_username=0x1e51710 "thom", agent_has_modify=1, setting_name=0x1e91f90 "802-11-wireless-security",
flags=NM_SETTINGS_GET_SECRETS_FLAG_ALLOW_INTERACTION, secrets=0x1e9f860, error=0x0, user_data=0x1deb2f0, other_data2=0x477d61 <get_secrets_cb>, other_data3=0x1ea92a0) at settings/nm-settings-connection.c:757
#6 0x00000000004dc4fd in get_complete_cb (parent=0x1ea6300, secrets=0x1e9f860, agent_dbus_owner=0x1ddb9e0 ":1.39", agent_username=0x1e51710 "thom", error=0x0, user_data=0x1dddf50) at settings/nm-agent-manager.c:1139
#7 0x00000000004dab54 in req_complete_success (req=0x1ea6300, secrets=0x1e9f860, agent_dbus_owner=0x1ddb9e0 ":1.39", agent_uname=0x1e51710 "thom") at settings/nm-agent-manager.c:502
#8 0x00000000004db86e in get_done_cb (agent=0x1e89530, call_id=0x1, secrets=0x1e9f860, error=0x0, user_data=0x1ea6300) at settings/nm-agent-manager.c:856
#9 0x00000000004de9d0 in get_callback (proxy=0x1e47530, call=0x1, user_data=0x1ea10f0) at settings/nm-secret-agent.c:267
#10 0x000000337380cad2 in complete_pending_call_and_unlock () from /lib64/libdbus-1.so.3
#11 0x000000337380fdc1 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#12 0x000000342800ad65 in message_queue_dispatch () from /lib64/libdbus-glib-1.so.2
#13 0x0000003370c492a6 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#14 0x0000003370c49628 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0
#15 0x0000003370c49a3a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#16 0x000000000042e5c6 in main (argc=1, argv=0x7fff75078e88) at main.c:644
Signed-off-by: Thomas Haller <thaller@redhat.com>
NMSettingSerial:parity was defined as a char-typed property that could
have the (case-sensitive!) values 'n', 'E', or 'o'. This is zany. Add
an NMSettingSerialParity enum, and use that instead.
g_object_class_list_properties() can't return NULL if called
correctly.
Also remove two failed attempts to use g_value_transform():
nm_setting_new_from_hash() was transforming src_value to its own type
(rather than to param_spec->value_type, which was presumably
intended), so it was a no-op (in addition to being unnecessary anyway,
since GObject will attempt to transform the value internally if
needed). And update_one_secret() was calling g_value_transform() on an
uninitialized GValue, so it would have always hit a
g_return_val_if_fail() in g_value_transform() if that code was ever
reached (which apparently it wasn't).
generate-plugin-docs.pl was assuming that it was being run out of
srcdir, and so failed in srcdir!=builddir builds (such as "make
distcheck"). Fix that.
Also, update .gitignore
The scripts extracts plugin description from document comments for particular
properties and builds a XML file out of the data. The XML file can be used
later for generating manual pages or other documentation.
Unfortunately, gtk-doc won't allow descriptions that would be separated from
the main gtk-doc stuff. But it is still useful to have plugin description bits
co-located with property definitions. We use our home-grown comments and parse
them ourself. Afterall it's not that bad, and in addition it brings us a
freedom in shaping the comments to our needs.
When removing/replacing a NMSetting in an NMConnection, we have
to disconnect setting_changed_cb() from the "notify" signal.
Backport commit dfba4ce1e1 from
libnm-core.
Signed-off-by: Thomas Haller <thaller@redhat.com>
verify() used to modify interface-name of the base settings. This is
discouraged, because verify() should not touch the connection.
For libnm-core we can change behavior and only modify the connection
in normalize().
Also, be more strict not to verify() sucessfully on invalid
interface-name.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Previously, NMSettingInfiniband:verify() silently modifies the
setting for invalid MTU. verify() should not do that.
For libnm-core we can change behavior and implement normalization
of MTU. This changes behavior for NMSettingInfiniband:verify() so
that MTU gets no longer fixed by verify() alone. Instead verify()
fails with a verification error.
Due the possibility to normalize the MTU, NM still can receive
invalid settings and fix it.
For libnm-core we don't change behavior, merely add a code comment.
Signed-off-by: Thomas Haller <thaller@redhat.com>
libnm-util is expected to end up behind the curve in terms of knowing
about new NMSetting properties, so if it sees an unknown property, it
should just assume that there will also be a backward-compatibility
equivalent rather than printing a warning.
(In particular, it should not warn when it sees the
"ipv4.address-labels" property now that it now longer knows about it.)
Rather than having test-crypto and test-setting-8021x be programs that
you have to pass arguments to to get them to run a single test, just
have them run all of the tests themselves.
This lets us get rid of the big "check-local" rule in Makefile.am and
just use TESTS to run everything.
https://bugzilla.gnome.org/show_bug.cgi?id=734388
test_libnm_linking() executes ./test-libnm-linking which
is supposed to crash. When the user set `ulimit -c unlimited`
before, this will leave a left-over core file.
In case of `make distcheck`, this is quite bad because it lets
the make target fail:
ERROR: files left in build directory after distclean:
./libnm-util/tests/core.31481
Fix this by setting the (soft) rlimit for writing core files
to 0 before executing the test binary.
Signed-off-by: Thomas Haller <thaller@redhat.com>
