jruby-openssl migration

[zzak]

/cc @headius @enebo @kares @mkristian

[tarcieri]

I'm guessing this is about merging jruby-openssl with this gem?

[zzak]

@tarcieri Exactly. We want to start working on merging the two gems into one codebase (including tests).

[tarcieri]

Sounds great! Let me know if I can help

[kares]

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) ?

[headius]

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.

[tarcieri]

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.

[kares]

first of all the current tests will need a way of excluding (just as we do run these as part of JRuby's suite).
for jruby-openssl there's actually a slightly different set of cases - some of which are Java/JRuby specific.
also there's integration tests e.g. run against different BC versions to maintain compatibility on that front.

[zzak]

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.

[mkristian]

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.

[tarcieri]

I'd be a fan of merging the two gems into a single repository. This is how nokogiri is managed, for example, and my nio4r gem also works this way.

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)

[hsbt]

I discussed @rhenium about this issue. He have concerns of licenses confliction.

[rhenium]

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.

[headius]

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).

[hsbt]

Thanks for explanation, it seems fine.

[headius]

Pinging @kares and @enebo to chime in here. Adding a -java gem that does not ship any C code and depends on our jruby-openssl should be a pretty simple PR to put together.

[enebo]

@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.

[headius]

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:

• Allow us to push openssl-java, which would basically just be a renamed jruby-openssl.
• Push a stub openssl-java that just depends on jruby-openssl.

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.

[headius]

I've pushed #598 which includes some tweaks to the gemspec to allow building a stub gem for JRuby. rake build appears to do the right thing when run under JRuby (or with appropriate RubyGems platform configuration), generating an openssl-java gem file that depends on jruby-openssl.

[yweiy10]

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?