This should fix SFTP not working when using GSConnect (which
doesn't specify the SSH parameters we do to allow old cyphers).
Requires API 23, so on pre-23 we still use RSA.
TLSv1.2 is supported on all the Android versions we support now.
TLSv1.3 is only supported in API 29+. Although we could conditionally
enable it on 29+, it seems to cause problems (disconnects & reconnects
when the LanLink gets refreshed) also on newer devices.
SpongyCastle was a fork of BouncyCastle needed before Android 3.0 because
of a conflict with Android's own version of BC. It's no longer needed and
rarely receives updates anymore [1]. Furthermore the version we were using
was from 2015 and had security issues (although I'm not sure we were
affected by them since we only use it to generate certificates).
With this change we now also use Java's standard library to read the certs
from a byte[] since the standard CertificateFactory can already do that.
[1] https://github.com/rtyley/spongycastle/issues/34
Removes conditional code for older Android versions (IceCreamSandwitch, JellyBean, KitKat, Lollipop) since we no longer support Android older than Lollipop (5.0).
This doesn't remove KitKat support in the SFTP plugin since it's a bit more convoluted. It will be done in a separate MR.
## Summary
Currently, KDE Connect for Android doesn't show the last 2 characters of the verification key when pairing a device. This MR solves this issue.
This bug is caused by incomplete conversions from byte arrays to strings in `SslHelper.java`:
```java
for (int i = 0; i < hash.length - 1; i++) {
formatter.format("%02x", hash[i]);
}
```
The ```i < hash.length -1``` converts the bytes in the array up to (inclusive) the penultimate one. Removing the ```- 1``` allows for the last byte to be converted (this is the missing 2 characters).
BUG: 445955
## Test Plan
### Before:
Selecting a desktop from the available devices, then clicking the `Request Pairing` button causes a 62 character key to be displayed. It is 2 characters short of the actual key, which can be seen on the desktop KDE Connect app.
### After:
Selecting the `Request Pairing` button now shows the whole verification key, as intended.
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.
This would happen to people who transferred their KDE Connect config from
one phone to another (mostly with backup apps that only work on rooted
phones). This led to a state where other devices would always reject the
connection because the certificate CN didn't match the device ID.
On the PC side this is not a problem because the certificate is the source
of truth for the device ID.
Summary:
Use the default configuration from Android
BUG: 400883
Test Plan: Pairing still works
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, thomasp, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D18219
Summary:
When receiving large files (even worse when uploading multiple files) the receiving socket
often times-out.
Test Plan:
Send 1 or 2 big files from desktop to android without this patch and you should see 1 or both transfers
fail because of a SO_TIMEOUT
Apply this patch and re-run the test and both transfers should now complete without an SO_TIMEOUT
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: zhigalin, albertvaka, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16758
Summary: Sorry for the huge diff, but all I did was applying Android Studio's 'Reformat Code' to all files. If everyone does that before submitting a patch we can keep it clean easily.
Test Plan: Compiles
Reviewers: #kde_connect, mtijink
Reviewed By: #kde_connect, mtijink
Subscribers: mtijink, sredman, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D10905
Summary:
Arch linux recently updated libraries which dropped support for RC4, used for connections to Android before Android 3 Honeycomb. Other distributions may also be affected (or will be affected in the future).
This adds a new cipher, supported by Android API 9+.
Test Plan: With this change (and corresponding desktop change) the app can connect again.
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Differential Revision: https://phabricator.kde.org/D9449
Fixed TLS version to TLSv1, this saves a connection failure due to TLSv1.2 hello message from devices with latest android versions
If device with new android version enquires about certificate from device with old version (<14) using setNeedClientAuth, connection fails on older device due to variation in certificate request code. So disabled server loop on older devices and using reverse connection hack for successful connection. But due to this, they can't connect to devices with similar android vesion since server is disabled on both and for a successful connection one should be server and one should be client
