-
Notifications
You must be signed in to change notification settings - Fork 165
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
jruby-openssl migration #20
Comments
I'm guessing this is about merging |
@tarcieri Exactly. We want to start working on merging the two gems into one codebase (including tests). |
Sounds great! Let me know if I can help |
interesting, I might have hoped Rails would at some point merge AR-JDBC but never thought of merging jruby-openssl :) just to double check, @zzak do you realize the JRuby version is not using any of the C (all of OpenSSL is re-invented using Java APIs and libraries) ? |
The main reason to do this merge is that folks are going to start depending on the gem 'openssl' in their applications. By having jruby-openssl pushed as the java version of openssl, they won't have to change their configs. They are definitely different codebases but I think ease of migration and management is more important than having the exact same code in both. |
The biggest benefit I can think of is a shared test suite that regression tests can be added to. We see jruby-openssl regressions rather frequently, and it would be great if we could send PRs for tests to this gem so the respective implementations can get fixed. |
first of all the current tests will need a way of excluding (just as we do run these as part of JRuby's suite). |
One thing I should mention, since the Java implementation will remain separate (but equal ), the tests however won't. I mean, I'd like to still be able to merge the tests from this gem into Ruby trunk, and have them pass on MRI. |
I do like one aspect of the joined gem: whenever the was a public security
with openssl the question what about jruby-openssl popped up and most of
the time it was not an issue with the jruby-openssl. having both
implementation in one gem will help in such situations.
|
I'd be a fan of merging the two gems into a single repository. This is how You can set up a Travis CI build matrix that runs the tests against both MRI and JRuby and can even have a separate matrix for testing various BouncyCastle versions. I would love to see every commit to both MRI openssl and JRuby vetted against such a test matrix. FWIW, I am about to spend the next 2 hours helping people to debug jruby-openssl bugs (and am literally in the middle of helping someone do this right now) |
I discussed @rhenium about this issue. He have concerns of licenses confliction. |
Sharing the test cases for common parts would be nice. I'm afraid it could be confusing if one gem contains two implementations with slightly different feature set, though. Anyway, since JRuby-OpenSSL is currently licensed under EPLv1/GPLv2/LGPLv2.1, none of these is compatible with CRuby's 2-clause BSDL, we can't start merging unless this is resolved. |
This never happened but I have a proposal for a simpler path forward: just release a -java openssl gem that depends on our jruby-openssl. We will be responsible for maintaining jruby-openssl, as now, and no major changes are needed to this repository. We would like to get this taken care of since more and more people are including openssl versions in their Gemfiles, which will not work on JRuby (without modification). |
Thanks for explanation, it seems fine. |
@headius This seems like a good idea to me. There could still need to be some level of coordination but it will decouple some amount of coordination for both impls to update their respective pieces of code. |
I would like to point out that the only real problem here is that the name "openssl" is currently only associated with the CRuby gem, which makes it impossible for any JRuby users to depend on it. That is the primary issue we need to fix. Since there are concerns about licensing (which we could fix), the next best options to merging this in directly are:
I believe the second option is probably the least impact, and it would not require merging any jruby-openssl code into the openssl gem. In any case, the only way for us to support the "openssl" gem name is by pushing a -java platform version of the gem for JRuby, as has been done for dozens of other gems with Java extensions versus C extensions. The openssl maintainers would not have to do anything other than make sure the stub gem gets released when the CRuby gem gets released, and we (JRuby maintainers) would be responsible for any issues in the jruby-openssl gem. I will try to put a proof-of-concept PR together this week. |
JRuby has its own implementation of the `openssl` library in jruby-openssl. The simplest way for us to allow users to set openssl as a gem dependency is to ship a stub gem that just depends on jruby-openssl. This patch adds that to the gemspec. Additional work may be required to fit this stub gem into the test and release process. See ruby#20 for more details.
I've pushed #598 which includes some tweaks to the gemspec to allow building a stub gem for JRuby. |
I see that OpenSSL has a support for FIPS mode, whereas JRuby-OpenSSL doesn't. Since it's depending on BC rather than OpenSSL C code I doubt it's a small effort to add the support. So what's the implication of this ticket to the case that a JRuby application wants to depend on this OpenSSL class to be FIPS compliant? |
/cc @headius @enebo @kares @mkristian
The text was updated successfully, but these errors were encountered: