Ruby 2.3 Update OpenSSL 1.0.2q to 1.0.2u

[MSP-Greg]

Built in forks, the OpenSSL test passed. I also added:

~/.rubies/ruby-${{ matrix.ruby-version }}/bin/ruby -ropenssl  -e 'puts "Build    " + OpenSSL::OPENSSL_VERSION, "Runtime  " + OpenSSL::OPENSSL_LIBRARY_VERSION, ""'

to the workflow yaml in ruby-install-builder in my fork. Outputs the version info, both were:

OpenSSL 1.0.2u  20 Dec 2019

which is a lot better than

OpenSSL 1.0.2q  20 Nov 2018

JFYI, Windows builds have generally always used the most recent MSYS2 package. But, since they have quite a few packages built with OpenSSL, they 'froze' at 1.0.2 and didn't update until 1.1.1 was released. Hence, some experience with 1.0.2 LTS, and never saw a release break anything...

[eregon]

Thank you for the PR.
It's indeed probably a good idea to use latest 1.0.2 (fewer bugs), even though OpenSSL 1.0.x is EOL.

I think it would be better to send this PR to https://github.com/rbenv/ruby-build and update all mentions of 1.0.2q. Could you do that?

Then I can rebase my branch which enables building OpenSSL on Linux.
I should probably send that change upstream too since getting OpenSSL 1.0.2 on Linux is so difficult nowadays.

[MSP-Greg]

Yes, I'll do a PR for ruby-build. Speaking of EOL, maybe add something to use-ruby-actions README like the following:

Older Rubies and the packages they are built with may be EOL.

In particular, Ubuntu & macOS 2.3.x and Windows 2.4 are built with OpenSSL 1.0.2. OpenSSL 1.0.2 is EOL and should not be used in applications where it is depended on for secure communications.

[eregon]

In https://github.com/eregon/use-ruby-action/#supported-versions there is already:

Note that Ruby 2.3 and the OpenSSL version it needs (1.0.2) are both end-of-life, which means Ruby 2.3 is unmaintained and considered insecure.

I didn't know RubyInstaller2 Ruby 2.4 binaries are built with OpenSSL 1.0.2, that's surprising since Ruby 2.4 supports OpenSSL 1.1.x. Can you double-check? Then I'll mention that in the README too.

[MSP-Greg]

Can you double-check?

Yes, 2.4.9 is 1.0.2t. OpenSSL 1.1.1 was released on 2018-09-11. Ruby 2.4.0 was released 2016-12.

Also, I may have mentioned that MSYS2 was slow to make a 1.1.1 package available.

Lastly, the openssl stdlib included in 2.4 was released before 1.1.1 existed. It was probably tested against 1.1.0, which 1.1.1 should be compatible with...

[eregon]

Thanks for checking, I'll add a note to the README.

That sounds like it could be worth to have newer builds of Ruby 2.4 in Ruby Installer 2, cc @larskanis.
That would avoid using unsupported OpenSSL with a supported Ruby version (well, until 2020-04-01, so it might not be worth it for 4 months until Ruby 2.4 is EOL).
I have no idea how much effort is that, just mentioning thoughts related to this.

[MSP-Greg]

Feel free to look my PR (review, approve, etc):
rbenv#1397

I split into two commits, one with the OpenSSL 1.0.2u changes, one with the cert code (which I just took from your original commit). All built and showed the correct OpenSSL version.

[eregon]

I forgot a bit about this, sorry.

Would you like me to update to OpenSSL 1.0.2u for 2.3.x builds of https://github.com/eregon/use-ruby-action ?
It shouldn't be too hard but the tricky part will be updating the existing release files as https://github.com/actions/upload-release-asset does not allow to do that (actually the GitHub API simply does not allow to replace an asset atomically). So I'll have to create a new release and copy files over.

[MSP-Greg]

Would you like me to update to OpenSSL 1.0.2u for 2.3.x builds

I (and I doubt others) are losing sleep over it, but I thought sometime...

the tricky part will be updating the existing release files

I've had the same thoughts re getting Ruby master on Actions. I've meant to try it by checking out the following PR, but haven't had a chance...

actions/upload-release-asset#22

[eregon]

That PR first delete the asset, so it's not atomic, there can be a time where there won't be any asset for that name. The GitHub API doesn't allow to directly either it seems.

@larskanis I'm not sure how files are updated for https://github.com/oneclick/rubyinstaller2/releases/tag/rubyinstaller-head but I guess there is also the same issue that there may be some time where the asset file is deleted and not re-added yet?

[larskanis]

@eregon Yes, release files are first deleted then uploaded again. So there are some seconds every day, where each file is not available. Upload code is here: https://github.com/oneclick/rubyinstaller2/blob/master/lib/ruby_installer/build/release.rb#L107-L116

That sounds like it could be worth to have newer builds of Ruby 2.4 in Ruby Installer 2, cc

I'll update from OpenSSL-1.0.2t to 1.0.2u with the next release of RubyInstaller-2.4.

[eregon]

This is done now, I rebuilt Ruby 2.3.x releases on Ubuntu & macOS using OpenSSL 1.0.2u:
https://github.com/eregon/ruby-install-builder/releases/tag/builds-newer-openssl
https://github.com/eregon/use-ruby-action/releases/tag/v1.6.0
https://github.com/eregon/use-ruby-action/runs/396832034 prints the OpenSSL versions.

FWIW I used a script to copy other release files: https://github.com/eregon/ruby-install-builder/blob/dceb96622a882df37d35819f9282390e49da8d08/generate-copy-yml.rb

[eregon]

@larskanis

I'll update from OpenSSL-1.0.2t to 1.0.2u with the next release of RubyInstaller-2.4.

I meant to update from OpenSSL 1.0.2t to OpenSSL 1.1.1, since OpenSSL 1.0.2 is end-of-life.
I understand that's a more risky change and might not be worth the effort since Ruby 2.4 should be EOL in ~4 months though.

Essentially I'd like to remove this warning in the README:
https://github.com/eregon/use-ruby-action#supported-versions

On Windows, Ruby 2.4 uses OpenSSL 1.0.2, which is no longer maintained.

[larskanis]

@eregon

I meant to update from OpenSSL 1.0.2t to OpenSSL 1.1.1, since OpenSSL 1.0.2 is end-of-life.

No - RubyInstaller-2.4 will stay on OpenSSL-1.0.2 since ruby's OpenSSL API is not fully compatible to the API when compiled against OpenSSL-1.1 (see here). I don't think 4 months difference in EOL time justifies an API break.

[eregon]

@larskanis Understood and fair enough.