NewPipe-legacy
NewPipe-legacy copied to clipboard
TeamNewPipe
Use Conscrypt
It would be nice if you used Conscrypt in NewPipe Legacy, so that you could use TLS 1.2-only services on Android devices that don't support TLS 1.2. It'll add a few MBs to the APK size though.
You can reuse this code: https://github.com/microg/android_packages_apps_GmsCore/blob/master/play-services-core/src/main/java/com/google/android/gms/common/security/ProviderInstallerImpl.java
Actually it would make sense doing it also in NOT legacy NewPipe to avoid using old TLS versions unnecessarily.
This file uses Conscrypt and another class from MicroG called PackageUtils
import org.conscrypt.NativeCrypto; import org.conscrypt.OpenSSLProvider; import org.microg.gms.common.PackageUtils
I mean using it as example, it should be adapted but 99% of it could be reused. The part of excluding packages obviously can be stripped.
Most devices running Android 4.1 (the minimum that NewPipe Legacy supports) will already make use of TLS 1.2. See https://github.com/TeamNewPipe/NewPipe-legacy/pull/19/commits/c439e19082e158792ded2ccf4e7fd761f142e21c & https://github.com/TeamNewPipe/NewPipe-legacy/pull/21/commits/d597cef7aa475f8311231090075382e620cefe56.
So you'd only need to add Conscrypt if the minimum API was lowered, which I don't think it will be due to the issues that introduces.
@blackbox87: That just enables it if it's built-in but disabled by default on your device, which unfortunately isn't the case on a lot of pre-KitKat devices, see e.g. https://ankushg.com/posts/tls-1.2-on-android/:
The first thing we realized was that despite documentation suggesting otherwise, not all devices on Android 4.1+ actually support TLS 1.2. Even though it is likely due to device manufacturers not fully following the official Android specs, we had to do what we could to ensure this would work for our users.
@wb9688 I know that there's a few that don't, but they're few and far between. In my experience most devices running Android 4.1 can use TLS 1.2 without any issues.
If a device doesn't support TLS 1.2 and a custom ROM can't be used then personally I'd want to encourage these people to upgrade their hardware, since these older versions of Android are vulnerable to so many exploits anyway.
@blackbox87: Well, NewPipe Legacy is meant for supporting legacy devices like that. For NewPipe, we also get a lot of reports from KitKat users, that their device doesn't support TLS 1.2. See e.g. TeamNewPipe/NewPipe#3728.
Well, NewPipe Legacy is meant for supporting legacy devices like that.
While this is true you'd be increasing the APK size by a few MB to support a few devices running out of spec vulnerable versions of Android. And in general most of these old devices don't have a lot of storage space to begin with, so that's not a fair trade off.
I think you'd be better off catching the throwable and then trying to use ProviderInstallerImpl or ProviderInstaller, depending on if the device is using microG or Google Play Services. That'll keep the file size down while fixing the problem.
@blackbox87: ProviderInstaller is part of Google's proprietary APIs (see https://developers.google.com/android/reference/com/google/android/gms/security/ProviderInstaller), so we can't use that.
@wb9688 In that case I'd suggest catching the throwable and attempting to use ProviderInstallerImpl. If it fails then you could then inform the user that their device isn't supported due to their buggy ROM.
I know that most of the people who have one of these buggy devices won't agree with me, but anyone who has a device that hasn't been butchered by the manufacturer probably doesn't want the size of the app to increase by a few megabytes.
In the thread that you previously linked to you said "Then it's not our issue. Upgrade to a newer Android version" and I agree with that. We shouldn't have to add a lot of code to fix issues within old buggy ROMs.
What about calling ProviderInstaller without compiling with Google libs but just using reflection? The code just need to detect if Google Play Services is installed (microG has the same package name) and if yes call it.
PS: This thing is always needed and future proof, what about when there will be TLS 1.3 only servers? Once the code is added new versions of TLS will appear without doing anything. Even new ROMs are updated just for a while then left alone... so it is still needed
Or create a separate package just with Conscrypt (called maybe "TLS update") and then the main NewPipe-legacy will call it if installed.
ProviderInstaller is out because it's proprietary software (an extreme minority of people use microG).
Please read the article above posted by @TobiGr
One abstract
It’s pretty easy to use (ProviderInstaller.installIfNeeded(context);) and fixes all those problems instantly. ) […] This sounds too good to be true, doesn’t it? Well, Google’s ProviderInstaller has a pretty big drawback. The library is closed-source, so it can not be used for apps published on F-Droid."
Antennapod has made a build flavor, one fully floss for F-Droid, the other one uses ProviderInstaller and is published to Play Store. We can also think of making a build flavor with Conscrypt.
I'm very interested too see what F-Droid will offer to fix this problem.
Google’s ProviderInstaller has a pretty big drawback. The library is closed-source
It is like this only if you USE the library, but you can probably avoid it with reflection. You can access it without knowing it at compile time.
Info: https://haptik.ai/tech/using-reflection-in-android/
In object-oriented programming languages such as Java, reflection allows inspection of classes, interfaces, fields and methods at runtime without knowing the names of the interfaces, fields, methods at compile time. It also allows instantiation of new objects and invocation of methods
If I'm not wrong the problem is only including closed source libraries, if you use an external app without any library linked in your app, like it was a command line tool I don't think there is any problem.