Closed MSP-Greg closed 2 months ago
Thanks @MSP-Greg for testing this! I'm not a big fan of supporting legacy crypto algorithms. Nevertheless OpenSSL provider support should work out of the box. So I'll fix this and add a test case.
I'm not a big fan of supporting legacy crypto algorithms
Agreed.
JFYI, in GitHub Actions, there are two MSYS2 mingw/ucrt archive files assembled. One has OpenSSL 1.1.1, and the other has 3.x. As you know, some of the Rubies have been built with OpenSSL 3.1.
When MSYS2 updated to OpenSSL 3.2, I kept an eye on several repos to see if there were problems (e.g. Puma, which compiles against OpenSSL, and also ruby/openssl). There didn't seem to be problems compiling against 3.2 but running on 3.1.
So, if you see any problems, please ping me.
Have a good New Year, and thanks, Greg
I want to see the legacy.dll
is located in searched paths or set a search path to find the legacy.dll
file.
In Ruby OpenSSL, we are setting the OPENSSL_MODULES
manually to find the legacy.dll
(legacy provider) as a workaround. However I hope the installer can can fix this issue so that we can remove the workaround.
As a note, the following openssl.exe
command can show the legacy provider if it is loaded in Windows. The https://github.com/openssl/openssl/issues/19368 may be helpful to understand this issue.
$ bin\openssl.exe list -provider legacy -providers
ruby/openssl added support for 'providers' in version 3.2, which is included with Ruby 3.3.0.
See https://github.com/ruby/openssl/pull/635
Due to the MSYS2 path changes, the single provider included with OpenSSL 3 (legacy.dll) should be located in
With that change, the following works:
I also puts the engines folder there, but I don't think 'engines' are supported with OpenSSL 3.2, not sure about earlier.
Sorry, I should have checked this earlier.
Happy Holidays, Greg