Tentatively marking for 9.4.8.0 because there's some important bits in there. It can be upgraded externally as a gem, so upgrading the bundled version is not as high a priority.

@headius thanks, the reason I had for upgrading the bundled version is that even with an upgrade, the old version is still present since rubygems doesn't delete uninstalled gems, much less those bundled with jruby.

@jsvd Was it causing a problem to have the old one? CVE or something similar? I did not follow the BC update thread.

Yes, we bundle JRuby in Logstash, and the old BC jars present trigger scanners on CVEs, even if they’re not being used.
We can delete the old files during packaging if needed, but would just prefer to have a CVE-free JRuby version.

Some of us are in the position where we need to use jruby-complete where jruby-OpenSSL is bundled, and yes, reports some noisy CVEs. (don’t ask, I’ve tried to switch GoCD to non bundled jars after the various SnakeYAML noise and gave up due to issues with unshaded dependency clashes and other mysteries with the GoCD build infrastructure 😅)

There were 4 CVEs fixed in BC 1.78: http://git.bouncycastle.org/releasenotes.html#r1rv78

Would be great to get this in, as has been stuck for a while (due to ASN1 compatibility problems that had to be solved with the 1.75 and 1.77 moves).

Okay. Multiple active CVE is definitely justification for upgrading in a minor release.

please do not edit pom.rb by hand without regenerating the pom.xml (could be done by doing ./mvnw validate).

was thinking we'll wait a bit longer, to smooth out any regressions (9.4.8.0 already included a minor JOSSL upgrade), but it's fine by me esp. since @headius wanted to take over the project maintenance.

@kares Given the long-standing CVEs I think it's better to get it out there now and deal with any fallout after the fact. Since it's a default gem, we just need it to work well enough to install gems, and from there users can down or upgrade as needed without the CVEs triggering problems.

Oh and related to the pom, I am hoping at some point in the future we will not version the pom.xml, since it's generated and read-only. But yeah for now we need those changes to come along at the same time.

Any chance we could get this backported to the 9.3 branch as well?

not against it, since 0.15 seems stable enough and tested against 9.3 as well but it's not the usual update to support in a "late" maintenance 9.3.x release. not even sure whether there will be another 9.3.x release at this point...

@beachtrash As @kares mentioned, there are no current plans for another 9.3 release. You should be able to update the jruby-openssl gem in existing 9.3 installs, though.

What is your specific need for 0.15 in 9.3.x?

I work for a large software company with a uniquely complicated internal dependency management and build system. The bouncycastle 1.78.1 library we need to pick up isn't supported by the 9.3.9.0 release we are currently using, so we tried to pull in jruby-openssl 0.15.0 ourselves. Our attempts to override the gem within our build/deps system have not yet been successful, but we realize these are largely from self-inflicted limitations, such as a preference for using official releases of open source rather than modifying the publicly-available bundle before publishing it internally. Our deps system has a focus on controlling which version of gems are provided rather than "required" and so we cannot easily override the "require" statements to strictly specify the higher version. Basically, adding gems and controlling their package versions is easy, but overriding built-in gems doesn't work (it's an us problem, I know). At runtime, it always seems to pick the bundled version despite 0.15.0 being available. The easiest solution for us would be if a version of 9.3.x magically appeared that solved our problem for us. Failing that, we probably have to take on the migration to 9.4 at this point.

So, any chance you'd be willing to backport 0.15.0 to the bundled 9.3.x branch?

I don't think there's any particular problem with upgrading 9.3 to the latest OpenSSL. However we are not doing regular releases of 9.3 at this point.

We would of course recommend upgrading to JRuby 9.4, but if you are in dire need of a 9.3 release perhaps we can work with your company to make that happen.

No need for the backport. We were able to patch the latest jruby-openssl gem into a build of our older release and it did get things working for us. We will move to the jruby 9.4 branch as we are able. Thanks for even considering it, though!