No need to require the caller to initialize the optional out-argument.
Otherwise we get:
(nm-connection-editor:2471): libnm-CRITICAL **: nm_utils_file_is_private_key: assertion 'out_encrypted == NULL || *out_encrypted == FALSE' failed
https://bugzilla.gnome.org/show_bug.cgi?id=763578
Fixes: 1c4f41c610
(cherry picked from commit 81499355b0)
This is required to add objects in the "Types and Values" section and
in the API index. Later, we may want to add useful content in those
empty comments.
(cherry picked from commit f1d23c32c3)
Closing the library will interfere badly as the glib types cannot be
unregistered. We must leak the library handle.
Switch to dlopen() instead of g_module_open(), because the former
supports RTLD_NOLOAD. This is useful for two reasons:
- checking the file prior loading only makes any sense when
dlopen() would actually load a file anew.
- if the library was loaded before, we want to return the handle.
On the other hand, if the library was not loaded, we leak the
handle.
Thereby, refactor the code from if-else blocks to return-early, because
the function nicely does individual steps and if one fails just error
out.
(cherry picked from commit 264189e756)
g_object_get_data() and g_object_get_qdata() end up to be identical,
except that g_object_get_data() also requires to intern the string
on every lookup (which involves a hash lookup and locking).
(cherry picked from commit d350d72a2e)
Otherwise the types links would be dangling or resolved to slightly
irrelevant documentation in libnm or completely irrelevant documentation
in libnm-util.
(cherry picked from commit db6ebe003d)
It isn't right in that context -- NMDevice is a libnm-core object,
not a bus object. In rendered documentation this would generate
a dangling link.
(cherry picked from commit c850868faf)
nmcli> set 802-1x.ca-cert file:///tmp/certs/eaptest_ca_cert.pem
(process:31015): libnm-CRITICAL **: crypto_is_pkcs12_data: assertion 'data != NULL' failed
Error: failed to set 'ca-cert' property: PEM certificate had no start tag '-----BEGIN CERTIFICATE-----'.
(cherry picked from commit 1d66d415b8)
In commit ca000cffbb, we changed to
accept a plugin library name without path. One reason for that
is to keep architecture dependent parts out of the .name file
and possibly support multilib.
However, the shared libraries of VPN plugins are not installed in
a global library search path, but for example into
"/usr/lib64/NetworkManager/libnm-vpn-plugin-openvpn.so".
In that case, specifying "plugin=libnm-vpn-plugin-openvpn.so"
would not be enough to find plugin.
Instead, when configuring a plugin name without path, assume
it is in NMPLUGINDIR directory. Modify nm_vpn_editor_plugin_load_from_file()
to allow path-less plugin-names. Previously such names would be rejected
as not being absolute. This API allows to do file verification
before loading the plugin, but it now supports prepending NMPLUGINDIR
to the plugin name. Basically, this function mangles the plugin_name
argument and checks that such a file exists.
The recently added nm_vpn_editor_plugin_load() continues to behave
as before: it does no checks whatsoever and passes the name directly
to dlopen(). That way, it uses system search paths like LD_LIBRARY_PATH
and performs no checks on the file.
Fixes: ca000cffbb
(cherry picked from commit 0b128aeced)
Since commit 3dfbbb227e, we enforce that
the plugin path in the .name file is absolute and we perform several
checks on the file before loading it (ownership, etc).
Relax that, to also allow libray names without path component.
In that case, g_module_open()/dlopen() will search for a library
in various search paths. This allows, to omit absolute paths
in the .name file. The latter is problematic, because by default
we install the .name file in the architecture independent location
/usr/lib/NetworkManager. As such, it should not contain paths
to architecture dependent libraries. With this change, a .name
file can contain only the library name and it will be loaded
using the usual mechanism.
However, specifying absolute paths is still possible and works
same as before, including checking file permissions.
As such, distributions probably should package the VPN plugins
to have no path in the .name file. On the other hand, a user
compiling from source probably wants to specify an absolute
path. The reason is, that the user probably doesn't build the
plugin for multiple achitectures and that way, he can install
the plugin in a separate (private) prefix.
(cherry picked from commit ca000cffbb)
The @plugin_filename argument must be an absolute path.
That was changed later, but forgot to update the comment.
Fixes: 3dfbbb227e
(cherry picked from commit cb22f02588)
Instead of looking into the keyfile, lookup the "supports-multiple-connections" setting
in the "keys" hash. This has some behavioral difference:
- g_key_file_get_boolean() first does g_key_file_get_value(), and then
converts the string using the private g_key_file_parse_value_as_boolean()
function -- which is case-sensitive, accepts "true|false|0|1" and
considers only the text until the first whitespace.
- now, we put g_key_file_get_string() into the cache "keys" and
parse it with _nm_utils_ascii_str_to_bool(). The latter is
case insensitive, allows also "yes|no|on|off", strips whitespaces.
However, the difference is subtle and shouldn't matter.
The point of this change is to free "keyfile" after construction.
(cherry picked from commit 6878999ca3)
Adding addresses with a prefix of zero is valid. Don't
reject them.
Note that this is an actual bug. If you configure an
address with prefix length zero, nmcli will report:
$nmcli connection
(process:1040): libnm-WARNING **: Ignoring invalid IP4 address: Invalid IPv4 address prefix '0'
(cherry picked from commit 57860c329e)
For internal compilation we want to be able to use deprecated
API without warnings.
Define the version min/max macros to effectively disable deprecation
warnings.
However, don't do it via CFLAGS option in the makefiles, instead hack it
to "nm-default.h". After all, *every* source file that is for internal
compilation needs to include this header as first.
The problem is that you cannot be sure which patches
were applied on top of a source tree, so the __nm_git_sha
value is unreliable.
Also, after running autoreconf during the package build,
NM_GIT_SHA is reset as well.
We cannot simply compare the single values of option hashes to match
connections because some keys are equivalent to others and also
because keys having a default value should be ignored.
Add the compare_property method to implement custom comparison logic.
When a value of a TYPE_BOTH option is read back from kernel it
contains both string and numeric values ("balance-rr 0"), so we must
chop off the number before adding the option to the setting. Also
change the default values of options to the string form so that the
option matching logic works.
No actual change, let's just not directly call nm_simple_connection_new_from_dbus().
Instead, add a wrapper to define in once place the flags we use for loading the
connection.
In some situations, we want strict checking of errors, for example when
NetworkManager receives a new connection from a client, the connection
must make sense as a whole (and since NetworkManager service is backward
compatible to the clients and not the other way around, there is no
excuse for sending invalid data to the server).
In other situations, we want a best-effort behavior. Like when
NetworkManager sends a connection to its clients, those clients
want to extract as many properties as they understand, but in order
to be forward compatible against newer server versions, invalid
or unknown properties must be accepted.
Previously, a mixture of both was done. Some issues caused a failure
to create a new NMSetting, other invalid parts were just silently
ignored or triggered a g_warning() in glib.
Now allow for both. When doing strict-validation, be more strict and
reject all unknown properties and catch when the user sets an invalid
argument. On the other hand, allow for a best-effort mode that
effectively cannot fail and will return a new NMSetting instance.
For now, add NMSettingParseFlags so that the caller can choose the
old behavior, strict parsing, or best effort.
This patch doesn't have any externally visible change except that
no more g_warnings will be emitted.
_nm_utils_ascii_str_to_int64() was declared in libnm-core's internal
header "nm-core-internal.h" and thus available for libnm-core, libnm,
NetworkManager and related.
It also means, the function was not available in libnm-util, libnm-glib,
clients or dispatcher. So, we either reimplemented it (nmc_string_to_int_base)
or struggle with the awkward strtol* API.
For some properties as *subject-match and *domain-suffix-match an
empty string means that we don't want to do any filtering and should
be stored as NULL.
The new domain-suffix-match and phase2-domain-suffix-match properties
can be used to match against a given server domain suffix in the
dNSName elements or in the SubjectName CN of the server certificate.
Also, add a comment to the old subject-match properties documentation
to suggest that they are deprecated and should not be used anymore.
GError codes are only unique per domain, so logging the code without
also indicating the domain is not helpful. And anyway, if the error
messages are not distinctive enough to tell the whole story then we
should fix the error messages.
Based-on-patch-by: Dan Winship <danw@gnome.org>
On older NM versions the default value for vlan.flags was 0, but then
the actual value set on interfaces was REORDER_HDR. In order to
maintain backwards compatibility in behavior, remove the special
handling of vlan.flags so that a missing key is treated as the default
value REORDER_HDR.
https://bugzilla.gnome.org/show_bug.cgi?id=762626
On NM 1.0 connections were created by default without the REORDER_HDR
flag, but then due to a bug in platform code (fixed in [1]), the
kernel interface always had the flag set.
Now that the setting is honored, users upgrading to the new version of
NM will see a change from the previous behavior, since interfaces will
not have REORDER_HDR and this will certainly break functionality.
The only solution here seems to be to ignore the REORDER_HDR variable
in ifcfg files (since it never had any effect) and introduce a new
NO_REORDER_HDR option for the VLAN_FLAGS variable which allows to turn
the flag off. The consequence is that the flag will be set for all old
connections.
This change introduces an incompatibility with initscripts, however is
necessary to avoid breaking user functionality upon upgrade.
Connections created through NetworkManager will still be parsed
correctly by initscripts (since we always write the REORDER_HDR
variable).
[1] db62fc9d72 ("platform: fix adding VLAN flags")
https://bugzilla.gnome.org/show_bug.cgi?id=762626
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
