Matters when backslash escaping ascii charaters <= 0xF, to
produce "\\XX" instead of "\\ X". For example tabulator is "\\09".
This also can trigger an nm_assert() failure, when building with
--with-more-asserts=5 (or higher).
We also do this for libnm and libnm-core, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.
Next we will use siphash24() instead of the glib version g_direct_hash() or
g_str_hash(). Hence, the "nm-utils/nm-hash-utils.h" header becomes very
fundamental and will be needed basically everywhere.
Instead of requiring the users to include them, let it be included via
"nm-default.h" header.
siphash24() mixes the bits much better then our naive xor.
Don't bypass siphash24(). We supposedly use it for the
better hashing properties, so use it also for pointers.
When using siphash24(), the hash value depends on the hashed input
and the key from _get_hash_key(). If the input is static, so is also
the result of siphash24(), albeit the bits are scrabbled more.
Add a nm_hash_static() to get such a static key, but without actually
doing siphash24(). The static key is also xored with a static_seed.
For that, also mangle the first byte of the hash key using siphash24()
itself. That is, because nm_hash_static() only uses the first guint of the
random key. Hence, we want that this first guint has all the entropy
of the entire key. We use siphash24() itself, to mangle all bits
of the 16 byte key into the first guint.
Currently there are multiple features that require Jansson support,
but WITH_JANSSON=1 is set only when configuring with
--enable-json-validation. Therefore a build with
"--disable-json-validation --enable-ovs" fails.
The availability of Jansson (WITH_JANSSON) should only be used:
- to check if dependent features can be enabled
- to determine compiler and linker flags in the Makefile
- in nm-jansson.h to define compatibility functions if needed
Everything else must be controlled by a configure switch.
https://bugzilla.gnome.org/show_bug.cgi?id=790233
Kernel doesn't support it for IPv6.
This is especially useful, if you combine static routes
with DHCP. In that case, you might want to get the device-route
to the gateway automatically, but add a static-route for it.
The number of authentication retires is useful also for passwords aside
802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
a retry counter and uses a hard-coded value of 3.
Move the setting, so that it can be used in general. Although it is still
not implemented for other settings.
This is an API and ABI break.
When the ifcfg-rh plugin writes a 802-1x setting it currently ignores
the password-raw property and so the password disappears when the
connection is saved. Add support for the property.
Normalizing can be complicated, as settings depend on each other and possibly
conflict.
That is, because verify() must exactly anticipate whether normalization will
succeed and how the result will look like. That is because we only want to
modify the connection, if we are sure that the result will verify.
Hence, verify() and normalize() are strongly related. The implementation
should not be spread out between NMSettingOvsInterface:verify(),
NMSettingOvsPatch:verify() and _normalize_ovs_interface_type().
Also, add some unit-tests.
There is no API to get all settings. You can only ask for
settings explicitly, but that requires you to probe for them
and know which ones may exist.
The alternative API might be nm_connection_for_each_setting_value(),
but that only iterates over settings' properties. If a setting has no
properties, it is ignored.
We want to support large number of routes. Reduce the number
of copies, by adding internal accessor functions.
Also, work around a complaint from coverity:
46. NetworkManager-1.9.2/libnm-core/nm-utils.c:1987:
dereference: Dereferencing a null pointer "names".
Previously, nm_setting_diff() would return !(*results), that means,
if the caller passed in a hash table (empty or not), the return value
would always be FALSE, indicating a difference.
That is not documented, and makes no sense.
The return value, should solely indicate whether some difference was
found. The only convenience is, if nm_setting_diff() created a hash
table internally and no difference was found, it would destroy
it again, without returning it to the caller.
NMSettingGeneric has no properties at all. Hence, nm_connection_diff() would report that
a connection A with a generic setting and a connection B without a generic setting are
equal.
They are not. For empty settings, let nm_setting_diff() return also empty difference
hash.
Since kernel commit a4176a9391868bfa87705bcd2e3b49e9b9dd2996 (net:
reject creation of netdev names with colons), kernel rejects any
colons in the interface name.
Since kernel could get away with tightening up the check, we can
too.
The user anyway can not choose arbitrary interface names, like
"all", "default", "bonding_masters" are all going to fail one
way or another.
teamd adds the "tx_hash" property for "lacp" and "loadbalance" runners
when not present. Do the same so that our original configuration
matches with the one reported by teamd.
https://bugzilla.redhat.com/show_bug.cgi?id=1497333
We often want to cascade hashing, meaning, to combine the
outcome of various hash functions in a larger hash.
Instead of having each hash function return a guint hash value,
accept a hash state argument. This saves the overhead of initializing
and completing the intermediate hash states.
It also avoids loosing entropy when we reduce the larger hash state
into the intermediate guint hash value.
By using a macro, we don't cast all the types to guint. Instead,
we use their native types directly. Hence, we don't need
nm_hash_update_uint64() nor nm_hash_update_ptr().
Also, for types smaller then guint like char, we save hashing
the all zero bytes.
siphash24() is wildly used by projects nowadays.
It's certainly slower then our djb hashing that we used before.
But quite likely it's fast enough for us, given how wildly it is
used. I think it would be hard to profile NetworkManager to show
that the performance of hash tables is the issue, be it with
djb or siphash24.
Certainly with siphash24() it's much harder to exploit the hashing
algorithm to cause worst case hash operations (provided that the
seed is kept private). Does this better resistance against a denial
of service matter for us? Probably not, but let's better be safe then
sorry.
Note that systemd's implementation uses a different seed for each hash
table (at least, after the hash table grows to a certain size).
We don't do that and use only one global seed.
