"nm-utils/nm-shared-utils.h" shall contain utility function without other
dependencies. It is intended to be used by other projects as-is.
nm_utils_random_bytes() requires getrandom() and a HAVE_GETRANDOM configure
check. That makes it more cumbersome to re-use "nm-shared-utils.h", in
cases where you don't care about nm_utils_random_bytes().
Split nm_utils_random_bytes() out to a separate file.
Same for hash utils, which depend on nm_utils_random_bytes(). Also, hash
utils will eventually be extended to use siphash24.
Introduce a NM_HASH_INIT() function. It makes the places
where we initialize a hash with a certain seed visually clear.
Also, move them from "shared/nm-utils/nm-shared-utils.h" to
"shared/nm-utils/nm-macros-internal.h". We might want to
have NM_HASH_INIT() non-inline (hence, define it in the
source file).
GArray's and GPtrArray's plen argument is unsigned. The index variable
to iterate the list, should not have a smaller range (or different data type).
Also, assert against negative idx argument.
CC libnm-core/libnm_core_libnm_core_la-nm-utils.lo
libnm-core/nm-utils.c:210:6: error: variable 'encodings' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
if (lang) {
^~~~
libnm-core/nm-utils.c:220:7: note: uninitialized use occurs here
if (!encodings) {
^~~~~~~~~
libnm-core/nm-utils.c:210:2: note: remove the 'if' if its condition is always true
if (lang) {
^~~~~~~~~~
libnm-core/nm-utils.c:198:30: note: initialize the variable 'encodings' to silence this warning
const char *const *encodings;
^
= NULL
Fixes: 28a0627481
Using plain numbers make it cumbersome to grep for
setting types by priority.
The only downside is, that with the enum values it
is no longer obvious which value has higher or lower
priority.
Also, introduce NM_SETTING_PRIORITY_INVALID. This is what
_nm_setting_type_get_base_type_priority() returns. For the moment
it still has the same numerical value 0 as before. Later, that
shall be distinct from NM_SETTING_PRIORITY_CONNECTION.
Teamd is not happy about them and would fail anyway. Worse even, if we
json_loads() such a JSON, which is precisely what happens when we inject the
"hwaddr" key, we turn bad JSON into a good one in a lossy matter. Not good.
https://bugzilla.redhat.com/show_bug.cgi?id=1455130
When the two base settings are present, use one of higher priority.
This will pick the "bridge" setting when both "bridge" and "bluetooth" are
present for a Bluetooth NAP connection.
Commit a8730c51c8 moved the enum
utils from libnm-core to shared/nm-utils.
However, three of those functions are part of public API in libnm.
So, when statically linking against "shared/nm-utils/nm-enum-utils.c"
and dynamically linking against libnm.so, those symbols are present
twice and cause a linker failure.
Fix that by moving the public API back to libnm-core.
Fixes: a8730c51c8
libnm contains the public function nm_utils_enum_from_str() et al.
The function is not flexible enough for nmcli's usecase. So, I would
need another public function like nm_utils_enum_from_str_full() that
has an extended API.
That was already required previously for ifcfg-rh writer, but in that
case I could just add it as internal API as libnm-core is linked statically
with NetworkManager.
I don't want to commit to a public API for an utility function. So move
the code instead to the shared directory, so that nmcli may link
statically against it and use the internal API.
nm_utils_enum_to_str() may also output numeric values if there is no
corresponding "nick" for the enum/flag value.
For enums the value is in decimal and for flags the value is hexadecimal
(with a "0x" prefix).
The same was already supported by nm_utils_enum_from_str() when reading
the value. However, previously, reading a flag would only support hex
numbers and reading a enum would only support decimal numbers.
Extend that, to allow passing numbers in any base. For nm_utils_enum_to_str()
also make sure to never output nicks that may be misinterpreted as
numbers.
It is not uncommon that a flags type has also the value 0 mapped,
for example to "unknown" or "none".
In that case, we should not return an empty string, but instead
that zero value.
Also, flags actually have an unsigned type. That isn't a real
problem to cast it to a signed int. But be more careful about
it and use unsigned while handling unsigned values and only
cast to int once.
Various libnm objects (addresses, routes) carry an hash table of
attributes represented as GVariants indexed by name. Add common
routines to convert to and from a string representation.
To parse a string, a knowledge of the supported attributes (and their
types) is needed: we represent it as an opaque type
NMVariantAttributeSpec that callers must query to the library for the
specific object type and pass to the parse function.
- for nm_utils_enum_to_str(), whenever encounter a numeric value
that has no expression as enum/flag, encode the value numerically.
For enums, encode it as decimal. For flags, encode it as hexadecimal
(with 0x prefix).
Also check that an existing value_nick cannot be wrongly interpreted
as a integer, and if they would, encode them instead as integers only.
- Likewise, in nm_utils_enum_from_str() accept numerical values
and for nm_utils_enum_get_values() return enum nicks that look
like numeric values in their numeric form only.
- In nm_utils_enum_from_str(), don't use g_strsplit(), but clone the
string only once and manipulate it inplace.
- Accept '\n' and '\r' as additional delimiters for flags.
- For consistency, also return an err_token for enum types. If the caller
doesn't care about that, he should simply not pass the out-argument.
Unfortunately nm_utils_enum_to_str() doesn't allow to specify the
separator between enum values. Since the function is public API and
can't be modified now, add a new internal function which accepts the
separator as argument.
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.
The function is used, among others, in the get_property() of many
objects to return a boxed strv from a list. The default value for a
boxed strv property is NULL, but _nm_utils_slist_to_strv() returns a
pointer to an array with zero elements when the list is empty.
Change the function to return NULL if the input list is empty.
nm_utils_hexstr2bin() is quite similar to hwaddr_aton(), and
nm_utils_bin2hexstr() is similar to _bin2str_buf().
Move them close to each other. Maybe one day they should be
consolidated. But their API is slightly different, so the
consolidation would require some effort.
For now, just move them close to each other, so that it's
clearer that two similar (but distinct) functions exists.
_nm_utils_hwaddr_length() did a validation of the string
and returned the length of the address. In all cases where
we were interested in that, we also either want to validate
the address, get the address in binary form, or canonicalize
the address.
We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton()
which both does the parsing and returning the length.
Backported symbols only make sense for libnm itself, not for
libnm-core which is statically linked with NetworkManager and
nm-ifcace-helper. Declaring the symbols in libnm-core, means
that NetworkManager binary also contains them, although there
are not used.
Move them to libnm.
Since we possibly already link against libjansson, we can also expose some
helper utils which allows nmcli to do basic validation of JSON without
requiring to duplicate the effort of using libjansson.
Also, tighten up the cecks to ensure that we have a JSON object at hand.
We are really interested in that and not of arrays or literals.
For "cloned-mac-address", the empty string "" is an invalid
value that is rejected by verify().
Commit 8eed671 changed how the property is serialized to D-Bus.
Before, it was serialized using _nm_utils_hwaddr_to_dbus().
For invalid or empty addresses, this would not serialize the
value on D-Bus (or before commit 76aa6f8e0, it would create
a bogus value with no array elements).
With commit 8eed671, the cloned-mac-address gets also serialized
as "assigned-mac-address" via _nm_utils_hwaddr_cloned_data_synth(),
which would pass on invalid strings that the server would then reject.
That breaks for example nmtui. Try editing a connection with
"cloned-mac-address" set to NULL. Note, as long as you don't edit
the cloned MAC address in nmtui, you can save the modification.
Once you start modifying the entry, you can no longer set an empty
MAC address as the server now receives the invalid empty string.
Thus, the "OK" button fails with
Unable to save connection:
802-3-ethernet.cloned-mac-address:
is not a valid MAC address
It also means, nmtui cannot modify the "cloned-mac-address" field to
become empty.
Fix that problem at various places by coercing "" to NULL.
Fixes: 8eed67122chttps://bugzilla.redhat.com/show_bug.cgi?id=1372799
