priv->path_cost and priv->priority can only be set as GObject properties,
which already does the same range check. Hence, the checks are never reached.
This also avoids a compiler warning:
libnm-core/nm-setting-bridge-port.c: In function ‘verify’:
libnm-core/nm-setting-bridge-port.c:132:22: error: comparison is always false due to limited range of data type [-Werror=type-limits]
if (priv->path_cost > BR_MAX_PATH_COST) {
^
The -Wimplicit-fallthrough=3 warning is quite flexible of accepting
a fall-through warning.
Some comments were missing or not detected correctly.
Thereby, also change all other comments to follow the exact
same pattern.
Previously, due to a bug in "tools/enums-to-docbook.pl", enum values
without explicit numeric value were wrongly parsed. That is fixed,
but still explicitly set the value in the public header.
IPv4 already allows setting an address, reusing its prefix for the network
it shares connection with. Additionally, for IPv6, the NDP can also share
the DNS configuration.
We should enable tests by default, probably we even should drop
the configure flags to enable tests and just always build them.
Anyway, at this point there is no use in guarding check-local
with a check for ENABLE_TESTS. A user who does't want to run
the tests, should just not call `make check`.
crypto_verify_private_key_data() must try to decrypt the key only when
a password is supplied.
Previously the decrypt test always passed because we detected an
unsupported cipher and faked success. Now since version 3.5.4 gnutls
supports PBES1-DES-CBC-MD5 and the key is actually decrypted when a
password is supplied.
Also, don't assert that a wrong password works because we're now able
to actually verify it (only with recent gnutls).
https://bugzilla.gnome.org/show_bug.cgi?id=771623
- don't include "nm-default.h" in header files. Every source file must
include as first header "nm-default.h", thus our headers get the
default include already implicitly.
- we don't support compiling NetworkManager itself with a C++ compiler. Remove
G_BEGIN_DECLS/G_END_DECLS from internal headers. We do however support
users of libnm to use C++, thus they stay in public headers.
We use statement expressions all over the place without explicitly
marking them. If that would be a problem, we'd have to change a
*lot* of code. We simply require that as a mandatory feature from
our compiler.
The "shared" directory contains files that are possibly used by all components
of NetworkManager repository.
Some of these files are even copied as-is to other projects (VPN plugins, nm-applet)
and used there without modification. Move those files to a separate directory.
By moving them to a common directory, it is clearer that they belong
together. Also, you can easier compare the copied versions to their
original via
$ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/
A failure to g_return*() by default prints a g_critical() with stringifing the
condition. Add a macro NMTST_G_RETURN_MSG() that reproduces that line to more
accurately match the failure message.
The linking test causes a crash to check whether libnm and libnm-util
are both linked. If abrt or systemd-coredump are enabled, the core
dump processing will take a long time when the address sanitizer is
enabled, due to the huge process address space. It seems a good choice
to disable the test when NM was compiled with -fsanitize=address.
This adds two new options to the configure scripts to compile NM,
clients and libraries with the address and undefined-behavior
sanitizers available in recent GCC versions. Clang is not supported at
moment.
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-----'.
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.
Add internal functions _nm_connection_replace_settings() and
_nm_connection_new_from_hash() that cannot fail.
Altough they are not public API, we have to expose them via
libnm-util.ver so that they can be used from libnm-glib.
Warnings aren't great, especially if they can realistically be triggered
by a newer NetworkManager version. Just accept what we can and ignore
the rest silently.
nm_connection_replace_settings_from_connection() would return whether the
connection verifies at the end of the operation. While that is not very
useful, the API is like that and cannot be changed.
For consistency, also perform the verification step in case of self-assignment.
Self-assigment is anyway a case that probably never happens.
nm_connection_replace_settings_from_connection() can safely be used
to copy an invalid connection. The return value only says, whether
the connection is valid after the fact.
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>
Functions that take a GError** MUST fill it in on error. There is no
need to check whether error is NULL if the function it was passed to
had a failing return value.
Likewise, a proper GError must have a non-NULL message, so there's no
need to double-check that either.
Based-on-patch-by: Dan Winship <danw@gnome.org>
Althoug we don't fully backport the new device types, at least
add the types to the NMDeviceType enum.
Based-on-patch-by: Jiří Klimeš <jklimes@redhat.com>
- 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
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
"nm-default.h". No need to include them separately.
- include "nm-macros-internal.h" via "nm-default.h" and drop all
explict includes.
- in the modified files, ensure that we always include "config.h"
and "nm-default.h" first. As second, include the header file
for the current source file (if applicable). Then follow external
includes and finally internal nm includes.
- include nm headers inside source code files with quotes
- internal header files don't need to include default headers.
They can savely assume that "nm-default.h" is already included
and with it glib, nm-glib.h, nm-macros-internal.h, etc.
Point in case:
# ip link add link dummy0 name dummy0.vlan type vlan id 4095
RTNETLINK answers: Numerical result out of range
This potentially causes existing (invalid) connections to disappear
as they now fail verification.
Instead of adjusting the range of the GObject property
NM_SETTING_VLAN_ID, reject it during vlan. This is a bit more
forgiving to an older client that isn't aware of this new restriction,
so he can first set the value without raising a critical warning.
