[
https://issues.apache.org/jira/browse/HBASE-28250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869196#comment-17869196
]
Nihal Jain edited comment on HBASE-28250 at 7/28/24 8:30 PM:
-------------------------------------------------------------
Hi posting progress here. I have some good news, I have been able to make our
shell run with JRuby 9.4.8.0.
*Root Cause Analysis*
It turns out the error "{_}NoMethodError: undefined method `gsub' for
nil:NilClass{_}" that we were getting with JRuby bump was due to the custom
JRuby implementation that we were having which has overtime become incompatible
with JRuby. For more info see HBASE-26741 where we "Override eval_input in HIRB
to modify exception handling logic".
This change was made when we were on [JRuby
9.2.13.0|https://github.com/petersomogyi/hbase/blob/9e399954bf8ffe89860e2faa040f5c6beee75e9c/pom.xml]
It's been a long while and a lot has happened in JRuby since then including
considerable changes in the irb.rb. In fact irb.rb in no longer part of JRuby
project as was in 9.2.13.0
[https://github.com/jruby/jruby/blob/9.2.13.0/lib/ruby/stdlib/irb.rb]
Now, JRuby relies on default gems as changed in
[https://github.com/jruby/jruby/commit/d17184ecacba208ff4be46d285a1e9eeed6a4994,]
thus we get irb via
[https://github.com/jruby/jruby/blob/9.4.8.0/lib/pom.rb#L58] and hence the
current irb.rb is coming via IRB gem project:
[https://github.com/ruby/irb/blob/v1.4.2/lib/irb.rb]
*Proposed fix*
As a short term solution, I have copied the eval_input method with the correct
version of irb and added our custom changes on top of it along with a required
change in output_value method. I have a WIP patch ready, and the changes work
fine for me based on local shell instance testing.
I am still testing more, need to test in a distributed env. Also, pending
changes for taking care of the licensing, if the current changes look fine to
others, will make licensing changes if any.
In long term, I plan to raise an request in IRB to allow overriding the error
handling code, maybe by refactoring code so that we do not have to
copy/override the eval_input method entirely. The current solution in place is
very error prone.
Here's the scan report post fix; which is a lot cleaner:
||THREAT||SECURITY ISSUE||CVSS SCORE||COMPONENT||
|-9-|-CVE-2022-1471-|-9.8-|-org.jruby : jruby-complete : 9.3.13.0-|
|-9-|-CVE-2022-1471-|-9.8-|-org.yaml : snakeyaml : 1.33-|
|-8-|-CVE-2024-27281-|-8.8-|-org.jruby : jruby-complete : 9.3.13.0-|
|-8-|-sonatype-2024-0946-|-7.7-|-org.bouncycastle : bcprov-jdk18on : 1.74-|
|-8-|-sonatype-2024-0946-|-7.7-|-org.jruby : jruby-complete : 9.3.13.0-|
|-8-|-CVE-2021-41819-|-7.5-|-org.jruby : jruby-complete : 9.3.13.0-|
|-8-|-CVE-2024-29857-|-7.5-|-org.bouncycastle : bcprov-jdk18on : 1.74-|
|-8-|-CVE-2024-29857-|-7.5-|-org.jruby : jruby-complete : 9.3.13.0-|
|-7-|-sonatype-2022-6090-|-6.1-|-org.jruby : jruby-complete : 9.3.13.0-|
|-7-|-CVE-2024-30171-|-5.9-|-org.bouncycastle : bcprov-jdk18on : 1.74-|
|-7-|-CVE-2024-30171-|-5.9-|-org.jruby : jruby-complete : 9.3.13.0-|
|-7-|-CVE-2024-30172-|-5.9-|-org.bouncycastle : bcprov-jdk18on : 1.74-|
|-7-|-CVE-2024-30172-|-5.9-|-org.jruby : jruby-complete : 9.3.13.0-|
|-7-|-CVE-2024-35176-|-5.3-|-org.jruby : jruby-complete : 9.3.13.0-|
|-7-|-sonatype-2013-0074-|-4.4-|-org.jruby : jruby-complete : 9.3.13.0-|
|7|sonatype-2022-6090|6.1|org.jruby : jruby-complete : 9.4.8.0|
|7|CVE-2024-35176|5.3|org.jruby : jruby-complete : 9.4.8.0|
|7|CVE-2024-39908|4.3|org.jruby : jruby-complete : 9.4.8.0|
|7|CVE-2024-39908|4.3|rexml 3.2.5|
|7|CVE-2024-35176|5.3|rexml 3.2.5|
was (Author: nihaljain.cs):
Hi posting progress here. I have some good news, I have been able to make our
shell run with JRuby 9.4.8.0.
*Root Cause Analysis*
It turns out the error "{_}NoMethodError: undefined method `gsub' for
nil:NilClass{_}" that we were getting with JRuby bump was due to the custom
JRuby implementation that we were having which has overtime become incompatible
with JRuby. For more info see HBASE-26741 where we "Override eval_input in HIRB
to modify exception handling logic".
This change was made when we were on [JRuby
9.2.13.0|https://github.com/petersomogyi/hbase/blob/9e399954bf8ffe89860e2faa040f5c6beee75e9c/pom.xml]
It's been a long while and a lot has happened in JRuby since then including
considerable changes in the irb.rb. In fact irb.rb in no longer part of JRuby
project as was in 9.2.13.0
[https://github.com/jruby/jruby/blob/9.2.13.0/lib/ruby/stdlib/irb.rb]
Now, JRuby relies on default gems as changed in
[https://github.com/jruby/jruby/commit/d17184ecacba208ff4be46d285a1e9eeed6a4994,]
thus we get irb via
[https://github.com/jruby/jruby/blob/9.4.8.0/lib/pom.rb#L58] and hence the
current irb.rb is coming via IRB gem project:
[https://github.com/ruby/irb/blob/v1.4.2/lib/irb.rb]
*Proposed fix*
As a short term solution, I have copied the eval_input method with the correct
version of irb and added our custom changes on top of it along with a required
change in output_value method. I have a WIP patch ready, and the changes work
fine for me based on local shell instance testing.
I am still testing more, need to test in a distributed env. Also, pending
changes for taking care of the licensing, if the current changes look fine to
others, will make licensing changes if any.
In long term, I plan to raise an request in IRB to allow overriding the error
handling code, maybe by refactoring code so that we do not have to
copy/override the eval_input method entirely. The current solution in place is
very error prone.
Here scan report post fix which is a lot cleaner:
||THREAT||SECURITY ISSUE||CVSS SCORE||COMPONENT||
|-9-|-CVE-2022-1471-|-9.8-|-org.jruby : jruby-complete : 9.3.13.0-|
|-9-|-CVE-2022-1471-|-9.8-|-org.yaml : snakeyaml : 1.33-|
|-8-|-CVE-2024-27281-|-8.8-|-org.jruby : jruby-complete : 9.3.13.0-|
|-8-|-sonatype-2024-0946-|-7.7-|-org.bouncycastle : bcprov-jdk18on : 1.74-|
|-8-|-sonatype-2024-0946-|-7.7-|-org.jruby : jruby-complete : 9.3.13.0-|
|-8-|-CVE-2021-41819-|-7.5-|-org.jruby : jruby-complete : 9.3.13.0-|
|-8-|-CVE-2024-29857-|-7.5-|-org.bouncycastle : bcprov-jdk18on : 1.74-|
|-8-|-CVE-2024-29857-|-7.5-|-org.jruby : jruby-complete : 9.3.13.0-|
|-7-|-sonatype-2022-6090-|-6.1-|-org.jruby : jruby-complete : 9.3.13.0-|
|-7-|-CVE-2024-30171-|-5.9-|-org.bouncycastle : bcprov-jdk18on : 1.74-|
|-7-|-CVE-2024-30171-|-5.9-|-org.jruby : jruby-complete : 9.3.13.0-|
|-7-|-CVE-2024-30172-|-5.9-|-org.bouncycastle : bcprov-jdk18on : 1.74-|
|-7-|-CVE-2024-30172-|-5.9-|-org.jruby : jruby-complete : 9.3.13.0-|
|-7-|-CVE-2024-35176-|-5.3-|-org.jruby : jruby-complete : 9.3.13.0-|
|-7-|-sonatype-2013-0074-|-4.4-|-org.jruby : jruby-complete : 9.3.13.0-|
|7|sonatype-2022-6090|6.1|org.jruby : jruby-complete : 9.4.8.0|
|7|CVE-2024-35176|5.3|org.jruby : jruby-complete : 9.4.8.0|
|7|CVE-2024-39908|4.3|org.jruby : jruby-complete : 9.4.8.0|
|7|CVE-2024-39908|4.3|rexml 3.2.5|
|7|CVE-2024-35176|5.3|rexml 3.2.5|
> Bump jruby to 9.4.8.0 to fix snakeyaml CVE
> ------------------------------------------
>
> Key: HBASE-28250
> URL: https://issues.apache.org/jira/browse/HBASE-28250
> Project: HBase
> Issue Type: Task
> Components: jruby, security, shell
> Reporter: Nihal Jain
> Assignee: Nihal Jain
> Priority: Major
> Labels: pull-request-available
>
> As a follow up of HBASE-28249, we want to bump to latest 9.4.x line here.
> This release line drops critical snakeyaml CVE ({*}org.yaml : snakeyaml :
> 1.33{*} having
> [CVE-2022-1471|https://nvd.nist.gov/vuln/detail/CVE-2022-1471]) from our
> classpath with following change along with several other bugs/fixes:
> * The Psych YAML library is updated to 5.1.0. This version switches the
> JRuby extension to SnakeYAML Engine, avoiding CVEs against the original
> SnakeYAML and updating YAML compatibility to specification version 1.2.
> [#6365|https://github.com/jruby/jruby/issues/6365],
> [#7570|https://github.com/jruby/jruby/issues/7570],
> [#7626|https://github.com/jruby/jruby/pull/7626]
> NOTE: JRuby 9.4.x targets Ruby 3.1 compatibility instead of Ruby 2.6 which
> 9.3.x were having!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
