Use smaller and safer EC keys, replacing 2048 bit RSA.
NID_X9_62_prime256v1 is roughly as secure as a 3072 bit RSA key, but way shorter.
Since we have to embed the key in the identity packet that is sent over UDP and
some stacks aren't happy with large UDP messages (notably: macos), I switched to
EC instead of to a longer RSA key.
This seems to be compatible with other clients even on older systems like Android 5.0.
I did stick with NID_X9_62_prime256v1 because stronger EC like NID_secp384r1 failed
the handshake (I didn't investigate why).
We now store the kind of key in the config, so we can know which kind of key we are loading.
The device ID is sanitized to make it safe for D-Bus, so the device ID
stored in the certificate as the subject name also needs to be
sanitized before comparison.
KDNSSD only works with Avahi (so, only on Linux) while mdns.h is a
header-only library [1] that implements mdns from scratch and should
work on all platforms.
[1] https://github.com/mjansson/mdns
We can always provide a function rather than a value.
This is what we do in most places already and is consistent with the
rest of KDE.
This gets compiled to the same code.
```cpp
explicit QLoggingCategoryMacroHolder(const QLoggingCategory &cat)
{
if (IsOutputEnabled)
init(cat);
}
explicit QLoggingCategoryMacroHolder(QMessageLogger::CategoryFunction catfunc)
{
if (IsOutputEnabled)
init(catfunc());
}
```
- Using QLatin1String when concatinating strings is faster, because they
are more lightweight. For the resulting string, we need to allocate
new memory anyway
- Use QLatin1String overloads where they are provided by Qt APIs
- Just use const char* for log messages, the quoting of QStrings is not
needed
- Make sure to reuse string results when possible
The rationale is explained in https://planet.kde.org/friedrich-kossebau-2023-06-28-include-also-moc-files-of-headers/
In case of KDEConnect, it impressively speeds up compilation. Before it
took 390 seconds on a clean build and with this change it took 330 seconds.
This is due to the mocs_compilation having to include the header files
and thus all their headers. Due to the lots of small plugins we have,
this means that the same headers must be compiled plenty of times.
When we include the moc files directly in the C++ file, they are already
available.
In theory we support Qt 5.6 (because of SailfishOS) but in practice we are not checking that in the CI so probably we broke the compatibility long ago. Also, I don't think anyone is using this code in SailfishOS, so we can greatly simplify the code by requiring Qt 5.15 or later.
Instead of always doing so on MacOS, do it only when we get a
DatagramTooLargeError. On MacOS, the size is limited only for
broadcast but not for unicast.
Since sockets are buffered `QIODevices` we can use `canReadLine()` to check
if we have a full line, instead of using a custom `SocketLineReader` class
(and the copy-pasted `DeviceLineReader` in the Bluetooth backend).
We can also loop through all the lines instead of queuing calls to `dataReceived`.
And we don't need transactions.
This whole code was no-op: it enumerates network interfaces, enumerates
its IP addresses, but does not change the address of broadcast UDP
packet, sending it only via default route/interface.
Bind the socket to IP addresses of the interfaces to fix the issue.
BUG: 459171
On FreeBSD 12 or later, a new routing strategy is introduced, which
prevents broadcast using 255.255.255.255.
Thus, we need to explicitly send the broadcast to each network
interfaces.
Here the commit can simply reuse the code for Windows.
Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252596
Detect the MTU on macOS and FreeBSD (which share the network parts of FreeBSD) and adaptively remove the outgoing and incoming capabilities.
The incoming capabilities are usually shorter, fit the size and help initialize the plugin list on the peer. This should fix an empty plugin list when the identity packet is sent by the macOS app.
If the MTU is still too short, both the capabilities need to be removed, which is not likely to happen.
Consider the following scenario:
1. We send a UDP broadcast
2. We receive a reply from 192.168.0.1 with device ID "foo"
3. We connect to 192.168.0.1, and find that the device's certificate
is actually for a different ID "bar". This could be because the
packet did not actually originate from 192.168.0.1, or this host is
malicious / malfunctioning.
4. We remember that device ID "foo" has certificate with common name "bar".
5. When we finally attempt to connect to the real device ID "foo", we
reject their certificate (common name "foo"). We can now never
successfully connect to "foo".
On some network (mis-)configurations, this completely prevents
kdeconnectd from connecting to any peers, because a reply which is
seen as originating from the local interface address will cause
kdeconnectd to immediately connect to itself and remember its own
certificate.
Address this by using the certificate display name of the peer, which
will match the real device ID.
Healthy identity packages shouldn't be that big and we don't want to
allow systems around us to send us ever humongous packages that will
just leave us without any memory.
Thanks Matthias Gerstner <mgerstner@suse.de> for reporting this.
