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.
The `QElapsedTimer` was never started. Clean it up somewhat and use a dedicated
250ms timer for reporting transferred bytes periodically (like KIO does it) and
1000ms for calculating speed so it's not as erratic.
Furthermore, report final numbers in `slotResult` rather than complicating
`slotProcessedAmount` for that.
Also, fix typo "send" -> "sent"
* Set magic `destUrl` property to let it know the job destination in case of
multiple files being transferred
* Set a normal "Receiving File(s)" title like we do with "Copying" title
* Set device name and destination path as details
The key is a sha256 of both devices' certificates. Both should generate the
same key, so hey user can check they are pairing against the right device.
Thanks Matthias Gerstner <mgerstner@suse.de> for reporting this.
We have a few places that open the KCM, with different arguments.
Centralize the implementation in one place.
This makes it easier to switch to invoking systemsettings5 in the future (once https://invent.kde.org/plasma/systemsettings/-/merge_requests/11 is in).
It also makes sure the relevant device is selected when clicking on a pairing notification.
The function is exposed to DBus for the Plasmoid and potential third-party users.
CCBUG: 425660
The package will arrive eventually, and dataReceived will be emitted.
Otherwise we just end up calling dataReceived to no end.
Thanks Matthias Gerstner <mgerstner@suse.de> for reporting this.
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.
We use kdeconnect-version.h in several places and therefore it needs to be in the include path. We currently do this by setting target_include_path in a few places. Replace this with an interface library that we can link against that sets up the correct include path. IMO it is cleaner this way.
This automatizes the generation of logging categories so a
kdeconnect-kde.categories is generated and installed to
/usr/share/qlogging-categories5/ so kdebugsettings can use it.
Also, sets the default logging level to Warning. So now the logs
of users won't be filled with debug messages but they can
modify the configuration easily with kdebugsettings.
clazy was complaining that the class had copy constructor but no assignment operator, which is usually suspicious
This is a bit of behaviour change though, since now m_payloadTransferInfo is also copied, which before wasn't, not sure if this is actually a good or a bad thing
Device::statusIconName depends on isReachable() and isTrusted()
Not sure how the property is used but it's good that they have a NOTIFY is defined if it's needed for completion
## Summary
LanLinkProviderTest fails on Windows. This patch fixes that.
I believe the root cause is that we are using a shared UDP socket to listen for identity broadcasts both in the LanLinkProvider and in the test. Apparently this works on Linux, but on Windows the LanLinkProvider picks up its own identity packet and pairs with itself.
This patch gives a parameter to LanLinkProvider to allow it to listen and broadcast on different ports, then uses that ability in the test to make the test pass on Windows.
## Test Plan
### Before:
lanlinkprovider test fails, first because it can't bind its UDP listener socket, and then because Windows seems to handle shared sockets differently than Linux, so the UDP broadcasts were not reaching the test's listener.
### After:
lanlinkprovider test seems to pass reliably both in my Windows VM and in the CI
pluginloadtest and sendfiletest are crashing. This patch fixes that by allowing Daemon::init() to be called from TestDaemon
## Test Plan
### Before:
Both tests are crashing because it is not able to find any devices. It is not able to find any devices because the LanLinkProvider is not being added because Daemon::init() is not being called.
### After:
pluginloadtest and sendfiletest pass
Summary: This tells the new notification system that we're copying a file and lets it show a better summary.
Test Plan:
{F6821356}
Is the composite job stuff already merged? That probably needs adjusting too
Reviewers: #plasma, nicolasfella
Reviewed By: nicolasfella
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D21182
