Does v3 of this gem always uses v3 of the C library?
collimarco opened this issue · comments
I add this to a gem (in the .gemspec):
spec.add_dependency 'openssl', '~> 3.0'
Then run bundle update and bundle exec rspec... all tests are passing. However it seems that the tests are failing for other people. Is that possible? My guess is that openssl gem v3 is using different underlying versions of the C library and that would be extremely confusing and problematic.
Can you please clarify this: does v3 of this gem always uses v3 of the C library?
If not:
- how can someone force the use of a specific version of the underlying C library?
- how can someone check what version of the underlying C library this gem is currently using?
Can you please clarify this: does v3 of this gem always uses v3 of the C library?
No
how can someone force the use of a specific version of the underlying C library?
Don't think so, it will use the version that was used when you compiled Ruby
how can someone check what version of the underlying C library this gem is currently using?
Read OpenSSL::OPENSSL_VERSION
Examples (rubies built by https://github.com/rbenv/ruby-build on macOS):
$ chruby-exec 2.7.6 -- ruby -ropenssl -e 'puts [RUBY_VERSION, OpenSSL::VERSION, OpenSSL::OPENSSL_VERSION]'
2.7.6
2.1.3
OpenSSL 1.1.1q 5 Jul 2022
$ chruby-exec 2.7.7 -- ruby -ropenssl -e 'puts [RUBY_VERSION, OpenSSL::VERSION, OpenSSL::OPENSSL_VERSION]'
2.7.7
3.0.1
OpenSSL 1.1.1s 1 Nov 2022
$ chruby-exec 3.1.2 -- ruby -ropenssl -e 'puts [RUBY_VERSION, OpenSSL::VERSION, OpenSSL::OPENSSL_VERSION]'
3.1.2
3.0.1
OpenSSL 3.0.5 5 Jul 2022
$ chruby-exec 3.2.0-preview3 -- ruby -ropenssl -e 'puts [RUBY_VERSION, OpenSSL::VERSION, OpenSSL::OPENSSL_VERSION]'
3.2.0
3.1.0.pre
OpenSSL 3.0.7 1 Nov 2022
how can someone check what version of the underlying C library this gem is currently using?
Note that OpenSSL::OPENSSL_VERSION is the version of OpenSSL that Ruby's OpenSSL was built with. OpenSSL::OPENSSL_LIBRARY_VERSION is the version of OpenSSL that Ruby's OpenSSL is running with. They may be different.
Note that the OpenSSL library files are named differently between 1.1.1 and 3.0, so the difference can only be 'within' an OpenSSL version.
how can someone force the use of a specific version of the underlying C library?
As @dentarg said. One can force the location used for the C library, but not the version. But, determining what versions of 'the underlying C library' are installed (and where) is messy and platform dependent...
Thanks for the details. All these different versions mixed together are a mess unfortunately :(
- Does Ruby 3 with openssl v3 gem work properly with C library v1.1? Or I MUST always use C library v3?
- If you use the Docker official image for Ruby, then how can you choose the C library version to use?
- Wouldn't be better to have the C library compiled as a native extension within ruby/openssl? This would make it easy to install, upgrade and version correctly the libraries.
Does Ruby 3 with openssl v3 gem work properly with C library v1.1?
Yes.
If you use the Docker official image for Ruby, then how can you choose the C library version to use?
Why would you need to?
to have the C library compiled as a native extension within ruby/openssl
Pros and cons. Files needed for runtime are different than files needed for compiling. Note that a few popular gems compile with OpenSSL, so there can be odd issues if a gem is compiled with one version of OpenSSL and Ruby's OpenSSL is compiled with another...
It's a coincidence that Ruby, Ruby/OpenSSL (openssl gem), and OpenSSL reached the major version number 3 on a similar timeline.
If it is absolutely necessary, Ruby/OpenSSL supports the --with-openssl-dir=<path> compile-time option to specify an installation of OpenSSL.