Statically link to Rustls instead of using OpenSSL

[charlespierce]

Info

• Implements the changes described in Switching to a Statically-Linked TLS implementation rfcs#47
• As discussed in the RFC, while using a statically-linked TLS implementation reduces our need to build for the unique CentOS flavor of OpenSSL, we still need to use an older version of Linux to link against an older glibc version.
• However, the build tools on CentOS 6 (the baseline for the glibc support that we've maintained) are too old to support building ring (a dependency of rustls).
• To work around that, I discovered a docker image for Scientific Linux CERN 6, which is based off of RHEL 6 (the same as CentOS).
  • The CERN distro includes its own mirror of the package repositories (in fact, we are already using the cern mirrors for CentOS 6 in our CI right now)
  • It also includes the ability to install more recent build tools, which allows us to compile ring

Changes

• Updated the dependency on attohttpc to enable the use of rustls instead of native-tls (OpenSSL on Linux)
• Created a Dockerfile that builds off of Scientific Linux CERN 6, installing updated build tools
• Updated the release CI workflow to build a single Linux version using the above Docker container.
• Updated the install script to look for the new single version in the case of Linux

Tested

• Confirmed locally using this Docker image that we are able to compile and run Volta
• Verified that the single Linux build artifact from CI runs correctly works on old CentOS Linux, recent Ubuntu, and latest Ubuntu (3 different OpenSSL versions).

Notes

• This PR changes the file name for the linux build artifact to be volta-{version}-linux.tar.gz, without the openssl-X suffix. This means we probably will need to roll it out in stages:
  • Pin the redirect for get.volta.sh to a commit hash, so that it isn't affected when this is merged. (Done in Pin get.volta.sh installer to current commit hash get#7) (Completed)
  • Merge this and prepare the release (along with any other features that we might want to include)
  • Test by fetching the new script directly to confirm that it works as expected.
  • Cut the release, then un-pin the get.volta.sh redirect so that it points at the updated script.
• We'll also need to update the "Installing Old Versions" section of the Installers docs to include another special-cased version of the install script, for people who want to install versions prior to the install script change.

[alvarlagerlof]

Would this mean that you wouldn't need openssl to install volta?

[charlespierce]

@alvarlagerlof Yes, exactly! That's actually one of the main motivations for this suggested change (see the linked RFC): Dealing with all of the different OpenSSL versions—trying to detect the appropriate one, fetch the correct binary, etc.—is a major pain point in our Linux installer. This would simplify all of that by statically linking to a Rust-based TLS/SSL implementation and avoiding all of the headaches that come with dynamically-linked OpenSSL.

[ZauberNerd]

@charlespierce I guess this PR would also allow #1049 to move forward, right?
I'm using volta on an EC2 with the Graviton2 ARM CPU and at the moment have to compile it myself, but would much prefer volta to release prebuilt binaries.

[charlespierce]

@ZauberNerd Yes, I believe this would allow that change to move forward as well, since it would remove the OpenSSL issues that ran into. The shift to Scientific Linux CERN 6 may also help alleviate the toolchain issues.

[ZauberNerd]

@charlespierce that's awesome! Is there something I could do to help get this PR out of the draft state?

[charlespierce]

@ZauberNerd I don't think there's anything left on this PR directly (other than resolving the merge conflicts). I'm leaving this in draft for now mostly to make sure that we don't accidentally merge it 😄 There's some infrastructure work we'll need to do before merging to make sure we don't break existing installs while we work towards the actual release of this change.

[chriskrycho]

@charlespierce what (if anything) can I do to unblock this over this coming week? Would love to help get it landed!

[charlespierce]

@chriskrycho I think the only thing remaining is landing this PR (and then some testing when we cut the release). My initial thoughts were being a little wary of version churn with the in-progress pnpm implementation, but I think there's enough significant changes between this and Yarn 3 support, plus there are some follow-ups needed for pnpm, so I'd lean towards getting this merged (along with any smaller outstanding PRs), and then cutting it all as version 1.1.

I'll update this to resolve the merge conflicts and also put out a PR to clean up some additional warnings we seem to be getting.

[chriskrycho]

That seems reasonable to me! Let's do it!

[chriskrycho]

Other than the one question, this looks good to me.

[charlespierce]

itshappening.gif

[nifr]

Wow this is huge! Thanks to everyone involved who helped to solve those openSSL linking issues with this PR.

Is it possible to get an "official" v1.1.0 release after the merge?

[chriskrycho]

That's precisely the plan—this and Yarn 3 support will be the headliner features! (With, hopefully, a 1.2 with pnpm support landing relatively soon after that. 🤞🏼)