-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Support OpenSSL 3.0 #399
Conversation
6648109
to
b46f3c8
Compare
I've tried to apply this PR on top of Ruby 3.0.1, and I'm experiencing a segfault on running test suite (failed when reading key). Any ideas how to fix that? Is that still expected? I'll appreciate any help. |
I assume that's why this PR is WIP. I think it's better to share why you want to run Ruby on the OpenSSL 3.0 "right now" without waiting the stable version if it is possible. That's helpful for people to know the proper context. As your colleague working in the same company, I know you are trying to build Ruby with OpenSSL 3.0 "right now". I think a possible solution might be to apply a patch to skip related logic by I think the steps to support OpenSSL 3.0 for Ruby is like this. I think what you can do to accelerate the steps is to contribute to step 1 first.
As a reference, this repo still does not have an openssl 3.0 case. openssl/.github/workflows/test.yml Lines 74 to 76 in 05e1c01
In my humble opinion, it might be also helpful for you to provide a reproductive script such as by using this repo's CI adding the OpenSSL 3.0 or using a container. Otherwise there might not be many things for people to help you here. |
The segfault is likely due to Yes, this is a work-in-progress and is not really ready. Please note that OpenSSL 3.0 is still in an alpha release and has not reached its feature freeze. |
It's not that I need it working "right now" (I'm not sure where did you get that impression). I'm trying to apply it now, for testing purposes, WRT Centos Stream 9. You're right, the PR is WIP, but that does not mean it's "development behind closed doors", right? I was trying to get the actual (usability) status, using combination of several PRs, and additional modifications, applied it to currently released Ruby (not a development version), as we plan to use it in the future. I may have applied the patch in a wrong way as well, so that's the part I'd be glad to get any feedback for.
Jun, if You think it's good to engage in upstream development, feel free to do it. I do not think it's mandatory to be able to have a conversation (give + receive feedback). I'll probably be able to engage more in upstream development in the future, but I'm afraid it's out of scope for me, currently.
|
Thank you!
Yes, AFAICT this is part of the "alpha" compatibility / readiness early testing (not directly by me), as we're encouraged to give feedback as well. |
Right. But I meant if you explain more context, it's better to open the door, not to surprise people. People are busy. It's better to think how to do for people to answer your question easily.
I just suggested a possible way for you to do. There is no pressure. |
ed548e1
to
a811750
Compare
The commit using this function (506be78) is now replaced by commit 01e1230. Some additional necessary changes for OpenSSL 3.0 support are also pushed to GitHub. It compiles with OpenSSL master (if all the warnings are ignored), but more work is still needed for the other part of OpenSSL::PKey. Also, as you can see in the GitHub Actions' output, many test cases are currently failing due to various reasons.
Thanks, this is helpful. |
Thanks! I might by able to try with newer openssl (from the package maintainer) later this week. Additionaly, I will try updating the ruby openssl gem to latest github state, to see whether I can achieve better result.
I'm glad to hear that, and I'll be happy to test further. |
c100521
to
c929071
Compare
Since Beta1 is already out, can I gently ask for an update? Thx a lot. |
A test failure due to a behavior change in OpenSSL 3.0.0 (openssl/openssl#16321):
A repro for convenience: require "openssl"
instance = OpenSSL::HMAC.new('key', 'SHA1')
a = instance
b = instance
exit 1 if a != b |
OpenSSL 3.0 is now released (and is now the default version on Homebrew) |
b29cef2
to
8681b66
Compare
I wonder, will the OpenSSL 3.x support be API compatible with older versions? Going through several PRs, it seems that it probably will, but there are so many changes (for better, I like what I have seen so far). |
Testing Puma against OpenSSL 3.x, I observer the following error:
It seems that this is caused by OpenSSL changing its behavior in EOF handling in openssl/ext/openssl/ossl_ssl.c Lines 1834 to 1835 in 8193b73
The issue is that now Checking this with @beldmit, I was given openssl/openssl/pull/11735 as an example to fix this issue. If I understand it correctly, it should be enough to set the |
I am not sure it's the best possible fix, but I had to introduce this option for backward compatibility with IIS, if I'm not mistaken. |
See also openssl/openssl#11209 (comment) |
This naive patch fixes the Puma issue:
@beldmit since you have mentioned IIS, do you think this should be better handled on server side and therefore should I report this issue to Puma? |
I wasn't aware of the behavior change. (This seems to be another case test code was missing.) Personally I've never been a fan of the current behavior of ruby/openssl, to treat unexpected EOF the same as a proper shutdown. This is for backwards compatibility, but it's a protocol error and potentially makes applications vulnerable to TLS truncation attack. IMO, this was something we needed to get rid of sooner or later. If OpenSSL now natively provides an option to turn on/off the behavior, it may make sense to let user decide.
In any case, we should provide a matching constant under OpenSSL::SSL namespace, just as we do for all other SSL_OP_* flags. |
openssl/ext/openssl/ossl_pkey_dh.c Lines 67 to 69 in 8193b73
Should the example above be updated to not use the deprecated |
86ad46e
to
be4a86a
Compare
65a35bb
to
bac56c5
Compare
Most of the patches I posted in this draft PR have been merged to
Our test suite now runs successfully with OpenSSL 3.0.1. However, we still use some deprecated functions in OpenSSL 3.0 and you will see a number of compilation warnings. The 3 commits remaining in this PR are wrappers for EVP_PKEY_todo() family. These would be nice to have on OpenSSL 3.0. |
How is the progress on this? I'm starting to test Jammy for server deployments and with libssl-dev 3.0.2 it won't compile as it's limited to |
EVP_PKEY_todata() returns all key components contained in an EVP_PKEY object as an array of OSSL_PARAM. This is useful as the replacement for low-level API which is used to implement #params. EVP_PKEY_todata() currently only exists in OpenSSL 3.0.0.
If EVP_PKEY_get_params() family is available, use it to get the key component values. Otherwise, check the return value of #to_data, which should be overriden by the subclasses.
Closing this PR, changes already landed on master branch two years ago. The openssl gem version 3.0.0 (released 2021-12) or later is compatible with OpenSSL 3.0. |
A collection of patches to support OpenSSL 3.0 API.
Currently, as of 2021-05-25, it compiles with OpenSSL's master branch (3.0.0-alpha17), but many things are known to be broken and test suite does not pass.
See also the tracking issue #369 (Support OpenSSL 3.0) for the summary.
These test failures are as of 2020-08, which may or may not be relevant today.
Test suite does not pass yet - some are due to unresolved issues in OpenSSL, which have open issues on openssl/openssl:
I haven't dug into others, yet: