Milestone stagnant

[matt-oc]

Just wondering is there any progress on this milestone, the assignee appears to be off the project and Its becoming much more prevalent as older devices and being left behind with the shift to TLS 1.2 and 1.3

https://github.com/google/conscrypt/milestone/6

[prbprbprb]

I can take a look at this (in my copious spare time :/ ) but trying to understand the impact. Android 4 is less than 0.1% of devices (according to apilevels.com) and TLS 1.0 and 1.1 are long deprecated, so who would this actually support?

Also note that while Conscrypt minSdk is currently 19, it will probably shift to 21 to match AndroidX/Play Services, so you'll probably need to prevail on somebody at Google to backport the fix to an older branch.

[matt-oc]

Android 4 would be minimal in the overall devices space but for certain segments such as epos devices and card machines android 4 is still actively being shipped on brand new devices for various reasons.

It's the older SDK devices that conscrypt is really useful for rather than higher SDK levels so it would be fantastic as TLS 1.3 becomes standard to be able to use it on such devices for integration with outside platforms as currently most only support up to TLS 1.2, so much of the world (using 4.x) is going to break when 1.2 is deprecated.

I have seen many reports of conscrypt working fine on android 4.2 and earlier so I'm not quite sure when it broke (I tried all versions and all were broken for me) or is this a bug that only affects emulators? (not actual devices, although I doubt it looking at the fact it uses extended libraries)

[prbprbprb]

OK, that changes the value proposition somewhat. I naively assumed that the embedded sector would be up around Android 7 or 8, but obviously those devices aren't going to show up and get counted on sites like apilevels.com.

There's a tension here between code health and legacy support. I think Google's focus is the Android platform itself and modern OpenJDK, so there would be a desire to remove legacy code and workarounds that support older platforms as it complicates feature development.

On the other hand, you neatly summarise the security/safety/standards case for making standalone Conscrypt available on older devices, especially those not supported by the Google Play ProviderInstaller API.

I think the first tension means minSdk 21 (or later) is inevitable at HEAD on the main branch. The 2.5.x branch should still build with minSdk 9, although it looks like the oldest emulator I can create is about API 16 (JB) which seems reasonable. I'll take a crack at that and see if I can reproduce the bug, because it's been so long that I forget the root cause. And maybe also see if the main branch will build with API 16...

As for emulator vs real devices, unless someone can give me access to a device or help test, I dunno.

I assume Google will accept any bugfix PRs for this for the 2.5.x branch, but getting them to do a signed Maven release might be significantly harder.

There's also the question of what BoringSSL to use. The 2.5.x branch is mostly 6 years old, and I'm sure it will build with BoringSSL from that time, but upgrading to anything more recent is likely to break things. Dunno if @davidben has an opinion here.

[matt-oc]

I appreciate the interest and efforts, in our segment there are million of devices still on android 4.x and with other similar areas I can't see how it wouldn't be 10's if not 100's of millions of devices this could help going forward.

Admittedly I am a bit ahead of the game, I was just doing some future proofing for TLS 1.3 when I came across the issue but it's really when TLS 1.2 is coming towards end of life there will be a huge influx of people requesting a fix or alternative.

I wouldn't expect devices that old to have the latest and greatest but keeping a branch that allows TLS 1.3 (and maybe even 1.4 when the time comes) and is compatible with API 16 on would certainly be a noble cause.

With regards the issue it seems that its trying to use X509ExtendedTrustManager rather than the normal TrustManager which doesn't exist in android versions that early.