Currently libnm headers include <linux/if_{ether,infiniband,vlan}.h>.
These are public headers, that means we drag in the linux header to all
users of <NetworkManager.h>.
Often the linux headers work badly together with certain headers from libc.
Depending on the libc version, you have to order linux headers in the right
order with respect to libc headers.
We should do better about libnm headers. As a first step, assume that
the linux headers don't get included by libnm, and explicitly include
them where they are needed.
Historically, keyfile read/write code was part of core, and thus
GPL-2.0+ licensed. Keyfile is the native file format for NetworkManager
connection profiles, and code to handle that should be part of libnm.
This would unlock many interesting features, like tools being able
to import/export connection profiles in the native file format.
However, libnm is LGPL-2.1+ licensed, so this is a problem.
The alternative would be to add a separate, GPL licensed library
(libnm-keyfile.so or libnm-gpl.so). However that also requires a larger
rework, because the current keyfile implementation uses internal API
from libnm-core and it would need to be reworked to only use public
API of libnm.
Relicense the code instead. According to research and "keyfile-history.sh"
script, the following individuals and companies possibly hold copyright
on the code:
<bgalvani(at)redhat.com>
<blueowl(at)centrum.cz>
<daniel(at)gnoutcheff.name>
<danw(at)redhat.com>
<dcantrell(at)redhat.com>
<dcbw(at)redhat.com>
<evan(at)ebroder.net>
<fgiudici(at)redhat.com>
<floe(at)butterbrot.org>
<j(at)bootlab.org>
<kmaraas(at)gnome.org>
<lkundrak(at)v3.sk>
<luzpaz(at)users.noreply.github.com>
<martinpitt(at)gnome.org>
<michael.i.doherty(at)intel.com>
<pavlix(at)pavlix.net>
<pmarti(at)warp.es>
<rafaelff(at)gnome.org>
<rstrode(at)redhat.com>
<tambet(at)gmail.com>
<tgraf(at)redhat.com>
<thaller(at)redhat.com>
<walters(at)verbum.org>
<yurchor(at)ukr.net>
Intel Corporation
Novell, Inc.
Red Hat, Inc.
Ximian, Inc.
Most contributors on this list agreed to relicensing according to RELICENSE.md.
The following copyright holders did not answer the request for agreeing
to relicensing:
- <j(at)bootlab.org>: no contributions were made that are related to
keyfile implementation. The script just gives a false positive.
- <pmarti(at)warp.es>: the contribution is a fix of a spelling error
(commit 6029288ffb).
- <tgraf(at)redhat.com>: the contribution to keyfile code are small
(I only identified commit 5b7503e95e).
Also, Thomas worked for Red Hat at the time.
After research, I think it's fair to conclude that everybody who holds
non-trivial copyright on the keyfile code agreed to the relicensing.
For historic reasons is NMSettingBond implemented differently from other
settings. It uses a strdict, and adds some validation on top of that.
The idea was probably to be able to treat bond options more generically.
But in practice we cannot treat them as opaque values, but need to know,
validate and understand all the options. Thus, this implementation with a
strdict is not nice.
The user can set the GObject property NM_SETTING_BOND_OPTIONS to any
strdict, and the setter performs no validation or normalization. That
is probably good, because g_object_set() cannot return an error to
signalize invalid settings. As often, we have corresponding C API like
nm_setting_bond_add_option() and nm_setting_bond_remove_option(). It
should be possible to get the same result both with the C API and with
the GObject property setting. Since there is already a way to set
certain invalid values, it does not help if the C API tries to prevent
that. That implies, that also add-option does not perform additional
validation and sets whatever the user asks.
Remove all validation from nm_setting_bond_add_option() and
nm_setting_bond_remove_option(). This validation was anyway only very
basic. It was calling nm_setting_bond_validate_option(), which can check
whether the string is (for example) and integer, but it cannot do
validation beyond one option. In most cases, the validation needs to
take into account the bond mode or other options, so validating one
option in isolation is not very useful.
Proper validation should instead be done via nm_connection_verify().
However, due to another historic oddity, that verification is very
forgiving too and doesn't reject many invalid settings when it should.
That is hard to fix, because making validation more strict can break
existing (and working) configurations. However, verify() already contains
basic validation via nm_setting_bond_validate_option(). So in the previous
behavior nm_setting_bond_add_option() would silently do nothing (only
returning %FALSE) for invalid options, while now it would add the
invalid options to the dictionary -- only to have it later fail validation
during nm_connection_verify(). That is a slight change in behavior, however it
seems preferable.
It seems preferable and acceptable because most users that call
nm_setting_bond_add_option() already understand the meaning and valid
values. Keyfile and ifcfg-rh readers are the few exceptions, which really just
parse a string dictionary, without need to understand them. But nmtui
or nmstate already know the option they want to set. They don't expect
a failure there, nor do they need the validation.
Note that this change in behavior could be dangerous for example for the
keyfile/ifcfg-rh readers, which silently ignored errors before. We
don't want them to start failing if they read invalid options from a
file, so instead let those callers explicitly pre-validate the value
and log an warning.
https://bugzilla.redhat.com/show_bug.cgi?id=1887523
Run:
./contrib/scripts/nm-code-format.sh -i
./contrib/scripts/nm-code-format.sh -i
Yes, it needs to run twice because the first run doesn't yet produce the
final result.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Seems with LTO the compiler can sometimes think that thes variables are
uninitialized. Usually those code paths are only after an assertion was
hit (g_return*()), but we still need to workaround the warning.
In practice, we wouldn't need the _WITH_MORE() variants here, because
all the suffixes that we check start with a ".", and we check first
that the filename itself does not start with a ".".
However, it doesn't hurt to be explicit about this, and it has no
overhead at all.
- in _keyfile_key_decode(), don't use GString. We know the maximum
string length before, so we can just allocated one buffer.
- in qdisc and tfilter writers, reuse the same GString instance.
No need to allocate a new temporary string buffer for each iteration.
- at other places, replace GString by NMStrBuf. This avoids the heap
allocated GString instance. Also, most operations can be inlined.
This results in larger code side, but avoids function calls to glib.
Originally, these files were part of libnm-core and linked together.
However, that is a licensing violation, because the code is GPL-2.0+
licensed, while libnm-core also gets linked with libnm (it must thus
be LGPL-2.1+). The original intent behind moving the code to "shared/"
was to avoid the licensing issue, but also to prepare when we would add
a separate, GPL licensed libnm-keyfile. However, currently we hope to
be able to relicense the code, so that it actually could be exposed as
part of libnm. This is work in progress at ([1]).
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/ ## 517
Anyway, the current directory layout is problematic. libnm-keyfile
depends on libnm-core, while libnm-core depends on code under shared.
That means, there is a circular dependency and meson's subdir() does
not work well.
Move the code.
2020-06-11 10:53:50 +02:00
Renamed from shared/nm-keyfile/nm-keyfile.c (Browse further)
