chore(deps): unpin openssl version

[rami3l]

Supersedes #3792. Effectively reverts #3692 and partially #3668.

[rami3l]

An update to NDK23 might be required for the Android CI issue:

I updated ndk 21.4.7075529 to ndk 23.2.8568313 it solved the problem.

openssl/openssl#18059 (comment)

[djc]

An update to NDK23 might be required for the Android CI issue:

I updated ndk 21.4.7075529 to ndk 23.2.8568313 it solved the problem.

openssl/openssl#18059 (comment)

What does that mean for rustup? Do we support Android? Does it mean there's a bunch of Android devices that we can no longer support?

[rami3l]

An update to NDK23 might be required for the Android CI issue:

I updated ndk 21.4.7075529 to ndk 23.2.8568313 it solved the problem.

openssl/openssl#18059 (comment)

What does that mean for rustup? Do we support Android?

We currently do (since #1000).

Does it mean there's a bunch of Android devices that we can no longer support?

Yes, but I'm sure it's coherent with the previous official announcement at https://blog.rust-lang.org/2023/01/09/android-ndk-update-r25.html.

[djc]

An update to NDK23 might be required for the Android CI issue:

I updated ndk 21.4.7075529 to ndk 23.2.8568313 it solved the problem.

openssl/openssl#18059 (comment)

What does that mean for rustup? Do we support Android?

We currently do (since #1000).

Does it mean there's a bunch of Android devices that we can no longer support?

Yes, but I'm sure it's coherent with the previous official announcement at https://blog.rust-lang.org/2023/01/09/android-ndk-update-r25.html.

Okay, sounds good then! Thanks for doing the legwork on this!

[rami3l]

@djc There's a "but" on this one: it's true that we have support for Android (termux) as a host platform since #1000, but:

1. We still don't have basic stuff like rustc and cargo for Android (termux) on our release server after like 8 years, so the fact that only we are supporting Android looks a bit weird (and could be misleading sometimes).
2. It could be a maintenance burden for us (oops, i686-linux-android is still failing!), so we in theory can drop it, and that will not violate the Rust Target Policy.

[djc]

I would be very on board with dropping the i686-linux-android target which seem exceedingly niche -- at least so far in that they don't represent real devices, but probably some kind of emulator?

[rami3l]

I would be very on board with dropping the i686-linux-android target which seem exceedingly niche -- at least so far in that they don't represent real devices, but probably some kind of emulator?

@djcThere are definitely real i686 Android devices but they are like at least ~10 yrs old I think. Even if I consider the current Termux user base, the actual share should be lower than 0.1% given that a huge portion of i686 Android users are on emulators.

Google says it's important to consider Chromebook users, a part of which are on x86 chips. However, they'll be mostly using x64 instead of the original x86, and it's also weird to me for them to use Termux since they are better off using a full-fledged x86_64-linux-gnu Rust installation via chroot or containers.

So yeah, I'm dropping i686-linux-android until things get easier. This target triple is also an edge case for the OpenSSL build process that few bother to care, it seems to me.