nm_device_get_device_type would report the device type as it was send on
DBus, while fetching the property would mean that only a known device
types is reported.
Make both results consistent by coercing in nm_device_get_device_type
rather than when setting the property.
(cherry picked from commit a6a185ba00)
The device type was set to the GType rather than a new value in the
NMDeviceType enum.
Add the corresponding enum entry, fix the device type and set the
routing priority to the same value as generic devices.
(cherry picked from commit 8d9365a973)
Support importing ".conf" files as `wg-quick up` supports it.
`wg-quick` parses several options under "[Interface]" and
passes the remainder to `wg setconf`.
The PreUp/PreDown/PostUp/PostDown options are of course not supported.
"Table" for the moment behaves different.
(cherry picked from commit a3a8583c31)
A NetworkManager client requires an API to validate and decode
a base64 secret -- like it is used by WireGuard. If we don't have
this as part of the API, it's inconvenient. Expose it.
Rename it from _nm_utils_wireguard_decode_key(), to give it a more
general name.
Also, rename _nm_utils_wireguard_normalize_key() to
nm_utils_base64secret_normalize(). But this one we keep as internal
API. The user will care more about validating and decoding the base64
key. To convert the key back to base64, we don't need a public API in
libnm.
This is another ABI change since 1.16-rc1.
(cherry picked from commit e46ba01867)
According to documentation, this returns a boolean indicating whether
the value is valid. Previously, it was indicating whether the instance
was modified.
Together with the @accept_invalid argument, both behaviors make some
sense. Change it, because that is also how the other setters behave.
(cherry picked from commit f3ac8c6fe8)
This is an API break since 1.16-rc1.
The functions like _nm_utils_wireguard_decode_key() are internal API
and not accessible to a libnm user. Maybe this should be public API,
but for now it is not.
That makes it cumbersome for a client to validate the setting. The client
could only reimplement the validation (bad) or go ahead and set invalid
value.
When setting an invalid value, the user can afterwards detect it via
nm_wireguard_peer_is_valid(), but at that point, it's not clear which
exact property is invalid.
First I wanted to keep the API conservative and not promissing too much.
For example, not promising to do any validation when setting the key.
However, libnm indeed validates the key at the time of setting it
instead of doing lazy validation later. This makes sense, so we can
keep this promise and just expose the validation result to the caller.
Another downside of this is that the API just got more complicated.
But it not provides a validation API, that we previously did not have.
(cherry picked from commit d7bc1750c1)
If we already specified "type" or "file", don't offer it for
completion again.
$ nmcli connection import type openvpn <TAB>
file type
(cherry picked from commit fea0f4a5ea)
[thaller@redhat.com: the code is effectively key_is_zero() by
<Jason@zx2c4.com> (LGPL2.1+). I took it into our source tree
and adjusted it to our style]
(cherry picked from commit 6234e41153)
- For PSK, an all-zero PSK means to don't do symmetric encryption. As such,
at first it seems a bit odd when the user sets
- preshared-key-flags != "4 (not-required)"
- preshared-key = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
Here the user indicates that a PSK is required, but then provides an
all-zero PSK that effectively disables it. Still, we should not reject
such a configuration. This has the benefit that it allos the user for
being prompted for a PSK, only to disable it by entering the all-zero key.
- For the private-key (and consequently the public-key), "public-key-flags=4"
is rejected by libnm. A private key is always required for NetworkManager to
configure the link. However, let's not care for all-zero keys either. If the user
configures that, we just set that key. It's a valid setting as far as WireGuard
(the kernel module) is concerned, so we shouldn't reject it.
(cherry picked from commit 78dccb8bb9)
In newer RPM file triggers in glibc package take care of this. While
these scriptlets whould do no harm there, removing them yields a tiny
theoretical performance improvement.
(cherry picked from commit a1e6afc0b2)
This is utterly pointless. %ldconfig_scriptlets expand to an empty
string on Fedora 28+.
This reverts commit ad836541cb.
(cherry picked from commit 3326a87953)
Group tag is not required, though is harmless. We could either remove it,
or keep it, but there's absolutely no excuse for conditionalizing it.
Let's keep it for now, because rpm -i still prints it.
This reverts commit 1feeba6f1a.
(cherry picked from commit 27418b1851)
nm_device_get_device_type would report the device type as it was send on
DBus, while fetching the property would mean that only a known device
types is reported.
Make both results consistent by coercing in nm_device_get_device_type
rather than when setting the property.
The device type was set to the GType rather than a new value in the
NMDeviceType enum.
Add the corresponding enum entry, fix the device type and set the
routing priority to the same value as generic devices.
Support importing ".conf" files as `wg-quick up` supports it.
`wg-quick` parses several options under "[Interface]" and
passes the remainder to `wg setconf`.
The PreUp/PreDown/PostUp/PostDown options are of course not supported.
"Table" for the moment behaves different.
A NetworkManager client requires an API to validate and decode
a base64 secret -- like it is used by WireGuard. If we don't have
this as part of the API, it's inconvenient. Expose it.
Rename it from _nm_utils_wireguard_decode_key(), to give it a more
general name.
Also, rename _nm_utils_wireguard_normalize_key() to
nm_utils_base64secret_normalize(). But this one we keep as internal
API. The user will care more about validating and decoding the base64
key. To convert the key back to base64, we don't need a public API in
libnm.
This is another ABI change since 1.16-rc1.
According to documentation, this returns a boolean indicating whether
the value is valid. Previously, it was indicating whether the instance
was modified.
Together with the @accept_invalid argument, both behaviors make some
sense. Change it, because that is also how the other setters behave.
This is an API break since 1.16-rc1.
The functions like _nm_utils_wireguard_decode_key() are internal API
and not accessible to a libnm user. Maybe this should be public API,
but for now it is not.
That makes it cumbersome for a client to validate the setting. The client
could only reimplement the validation (bad) or go ahead and set invalid
value.
When setting an invalid value, the user can afterwards detect it via
nm_wireguard_peer_is_valid(), but at that point, it's not clear which
exact property is invalid.
First I wanted to keep the API conservative and not promissing too much.
For example, not promising to do any validation when setting the key.
However, libnm indeed validates the key at the time of setting it
instead of doing lazy validation later. This makes sense, so we can
keep this promise and just expose the validation result to the caller.
Another downside of this is that the API just got more complicated.
But it not provides a validation API, that we previously did not have.
[thaller@redhat.com: the code is effectively key_is_zero() by
<Jason@zx2c4.com> (LGPL2.1+). I took it into our source tree
and adjusted it to our style]
- For PSK, an all-zero PSK means to don't do symmetric encryption. As such,
at first it seems a bit odd when the user sets
- preshared-key-flags != "4 (not-required)"
- preshared-key = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
Here the user indicates that a PSK is required, but then provides an
all-zero PSK that effectively disables it. Still, we should not reject
such a configuration. This has the benefit that it allos the user for
being prompted for a PSK, only to disable it by entering the all-zero key.
- For the private-key (and consequently the public-key), "public-key-flags=4"
is rejected by libnm. A private key is always required for NetworkManager to
configure the link. However, let's not care for all-zero keys either. If the user
configures that, we just set that key. It's a valid setting as far as WireGuard
(the kernel module) is concerned, so we shouldn't reject it.
In newer RPM file triggers in glibc package take care of this. While
these scriptlets whould do no harm there, removing them yields a tiny
theoretical performance improvement.
Group tag is not required, though is harmless. We could either remove it,
or keep it, but there's absolutely no excuse for conditionalizing it.
Let's keep it for now, because rpm -i still prints it.
This reverts commit 1feeba6f1a.
The condition got accidentally reversed, which means we're always
undecided and thus wrongly assuming support and never being able to set
any addresses.
This would bother the few that are struck with 3.4 android kernels. Very
few indeed, given this got unnoticed since 1.10.
Fixes: 8670aacc7c ('platform: cleanup detecting kernel support for IFA_FLAGS and IPv6LL')
(cherry picked from commit d551a0893e)
