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 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.
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.
## 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
