You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
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 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)
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).
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.
@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:
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.
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.
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?
Activity
tarcieri commentedon Aug 5, 2015
I'm guessing this is about merging
jruby-opensslwith this gem?zzak commentedon Aug 6, 2015
@tarcieri Exactly. We want to start working on merging the two gems into one codebase (including tests).
tarcieri commentedon Aug 6, 2015
Sounds great! Let me know if I can help
kares commentedon Aug 6, 2015
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 commentedon Aug 6, 2015
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 commentedon Aug 9, 2015
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 commentedon Aug 9, 2015
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 commentedon Aug 11, 2015
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 commentedon Aug 11, 2015
tarcieri commentedon Aug 11, 2015
I'd be a fan of merging the two gems into a single repository. This is how
nokogiriis managed, for example, and mynio4rgem 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)
[-]jruby[/-][+]jruby-openssl migration[/+]hsbt commentedon Nov 2, 2016
I discussed @rhenium about this issue. He have concerns of licenses confliction.
rhenium commentedon Nov 7, 2016
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 commentedon Jan 27, 2022
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 commentedon Jan 27, 2022
Thanks for explanation, it seems fine.
headius commentedon Jan 27, 2022
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 commentedon Jan 27, 2022
@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 commentedon Feb 1, 2022
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.
Stub gemspec for JRuby
headius commentedon Feb 8, 2023
I've pushed #598 which includes some tweaks to the gemspec to allow building a stub gem for JRuby.
rake buildappears 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 commentedon Oct 11, 2023
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?
rhenium commentedon Oct 16, 2026
FYI, #598 was merged and openssl >= 3.2.0 (released in 2023) is a stub gem that just depends on jruby-openssl on JRuby.
I'm closing this issue for now.
headius commentedon Oct 17, 2026
FWIW, jruby-openssl also has FIPS mode now.