feat(openssl): strip unnessary openssl features

[Cloud0310]

This fixes previouse android ci/cd error, and further strips some of the openssl parts to improve build speed and size.

Also fixes #5007, allowing for future further reductions about openssl build.

[djc]

#4979 was already fixed, and this seems to add a bunch of complexity. Not sure it's worth it?

[rami3l]

@djc I just discussed with @Cloud0310 and we agree that:

• ci(docker/android): stop building OpenSSL #4978 is kind of a special-case hack for Android.
• Actually the root cause of Broken x86_64-linux-android build caused by OpenSSL #4979 is the newly-added SM3/SM4 support in OpenSSL which is not actually used anywhere in this project, however our CI is carrying the burden of that update.
  • This might thus indicate that there is a set of features we can disable permanently in the vendored OpenSSL build and, if the OpenSSL binding is updated further to build even more stuff than we care about, we can disable those new features in a similar fashion.

[Cloud0310]

#4979 was already fixed, and this seems to add a bunch of complexity. Not sure it's worth it?

To me this is better in two ways:

1. Linux artifact size

Comparing the binary size main run with the PR run, excluding Android targets:

Linux target	Main	PR	Reduction
aarch64-unknown-linux-gnu	7.64 MB	7.10 MB	0.54 MB (7.1%)
armv7-unknown-linux-gnueabihf	6.40 MB	6.36 MB	0.04 MB (0.6%)
x86_64-unknown-linux-gnu	7.44 MB	7.41 MB	0.03 MB (0.4%)

The largest reduction is for aarch64-unknown-linux-gnu.

Android build is also fixed with this PR.

2. Making openssl upgrade more error prone.

this seems to add a bunch of complexity

It's due to my local config problem, I used format on save, causing the change bloat, actually it's just less then 10 lines.

And as for the potential problem of stripping out wrong binary section, I've verified the x86_64-unknown-linux-gnu binary works after the patch manualy within a fresh debian container locally.
Another point is if openssl build fails in the future, we can have a direct way of controling build configure to fix this directly on our side.

[djc]

I don't consider a 7%/0.5MB win for adding shell script calling into OpenSSL configuration worth it.

[djc]

2. Making openssl upgrade more error prone.

Did you mean less error prone? How/why would it be less error prone?

[Cloud0310]

2. Making openssl upgrade more error prone.

Did you mean less error prone? How/why would it be less error prone?

With a hack like this, we can even strip down further to the minimal stable feature set of openssl, as long as the specific feature stays buildable, we can make sure later versions won't affect or ci build.

[djc]

2. Making openssl upgrade more error prone.

Did you mean less error prone? How/why would it be less error prone?

With a hack like this, we can even strip down further to the minimal stable feature set of openssl, as long as the specific feature stays buildable, we can make sure later versions won't affect or ci build.

You're adding a hack. We have to maintain that hack potentially forever. It doesn't seem like a good trade-off to me. In my mind we want to maintain OpenSSL support as little as possible.

[rami3l]

In my mind we want to maintain OpenSSL support as little as possible.

@djc I 100% agree with this stance, but according to my experience maintaining the CI, it looks like:

• Either we will have to remove OpenSSL builds entirely, or at least from our official builds, at which point both this PR and ci(docker/android): stop building OpenSSL #4978 will lose their meaning;
• Or issues like this will reoccur even if we lower the tier of support to "guaranteed to build only", and it's always been a whack-a-mole game since a few years ago for me: each time our OpenSSL version is bumped and it breaks something, I have to either downgrade/pin the OpenSSL version in order to make the release pipeline pass, or add a hack to achieve the same result. I am not aware of the best way to lower our maintenance burden in that case, maybe we can just stick to the old ways...

In any way, I think hacking on this repo is not working on the right abstraction level; as such, I think this PR can be closed now.

[djc]

@cuviper do you know people who could help keep OpenSSL support working in rustup?

[cuviper]

I can probably help when it comes to linux-gnu targets, at least, although I haven't seen what's been challenging for you. For this case with android, I don't have much expertise to add, but don't we also build openssl-src for cargo in rust-lang/rust dist CI?