Fedora has issued an advisory on April 21: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/XMDCWRQXJQ3TFSETPCEFMQ6RR6ME5UA3/ The issue is fixed upstream in 1.13.4: https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-crjr-9rc5-ghw8 Additionally, it doesn't seem to use the system nekohtml, so is probably bundling the fork which is affected by CVE-2022-24839: https://github.com/sparklemotion/nekohtml/security/advisories/GHSA-9849-p7jc-9rmv Whether the system nekohtml is affected is not clear, but it sounds like only nokogiri on JRuby is affected by this issue. Very confusing. Mageia 8 is also affected.
Whiteboard: (none) => MGA8TOOStatus comment: (none) => Fixed upstream in 1.13.4CC: (none) => java, mageia
nokogiri when built as native module for ruby is C code using libxml2 while when built for jruby it is java code based on xerces. We don't provide the jruby binary, so I believe we are not affected by CVE-2022-24839.
That sounds right. Do you have any idea if our nekohtml package (which is java) is affected?
ruby-nokogiri-1.13.4-1.mga9 uploaded for Cauldron by Pascal.
Whiteboard: MGA8TOO => (none)Version: Cauldron => 8
ruby-nokogiri-1.11.1-1.1.mga8 is currently being uploaded (that's quite a few 1s). Suggested reproducer: time ruby -rnokogiri -e 's="<?xml " + (" " * 40000); s.encode!("ASCII-8BIT"); Nokogiri::HTML(s)' Here before the update it takes 15s, after the update it takes 0.08s
ruby-nokogiri-1.11.1-1.1.mga8 ruby-nokogiri-doc-1.11.1-1.1.mga8 from ruby-nokogiri-1.11.1-1.1.mga8.src.rpm
Status comment: Fixed upstream in 1.13.4 => (none)Assignee: pterjan => qa-bugsCC: (none) => pterjan
mga8, x86_64 Removed ruby gem nokogiri. Installed ruby-nokogiri. Tried Pascal's reproducer. Before update: $ time ruby -rnokogiri -e 's="<?xml " + (" " * 40000); s.encode!("ASCII-8BIT"); Nokogiri::HTML(s)' real 0m5.181s After update: $ time ruby -rnokogiri -e 's="<?xml " + (" " * 40000); s.encode!("ASCII-8BIT"); Nokogiri::HTML(s)' real 0m0.076s Used the bundled gem to parse an XML playlist. $ irb irb(main):001:0> require "nokogiri" => true irb(main):002:0> file = "channels.xspf" => "channels.xspf" irb(main):003:0> doc = File.read( file ) => "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<playlist xmlns=\"h... irb(main):004:0> check = Nokogiri::XML( doc ) => #<Nokogiri::XML::Document:0xec68 name="document" children=[#<Nok... irb(main):005:0> puts check.errors => nil Likewise for a 6 MB HTML file. irb(main):007:0> file = "bookmarks.html" => "bookmarks.html" irb(main):008:0> html = File.read( file ) => "<!DOCTYPE NETSCAPE-Bookmark-file-1>\n<!-- This is an automatica... irb(main):009:0> doc = Nokogiri::HTML( html ) => #<Nokogiri::HTML::Document:0x943cc name="document" children=[#<N... irb(main):010:0> puts doc.errors [...] 3721:127: ERROR: htmlParseEntityRef: expecting ';' 3721:140: ERROR: htmlParseEntityRef: expecting ';' => nil irb(main):011:0> puts doc.errors.length 1315 <In fact these errors don't seem to affect a browser.> I have no useful knowledge of this subject so tried a simple example at https://riptutorial.com/nokogiri. $ irb search.rb search.rb(main):001:0> require 'nokogiri' => true search.rb(main):002:0> search.rb(main):003:0> doc = Nokogiri::HTML(<<EOT) search.rb(main):004:-" <html> search.rb(main):005:-" <body> search.rb(main):006:-" <p>foo</p> search.rb(main):007:-" <p>bar</p> search.rb(main):008:-" </body> search.rb(main):009:-" </html> search.rb(main):010:-" EOT => #<Nokogiri::HTML::Document:0x17c name="document" children=[#<Nokogiri::X... search.rb(main):011:0> search.rb(main):012:0> doc.search('p').text # => "foobar" => "foobar" search.rb(main):013:0> doc.search('p').map(&:text) # => ["foo", "bar"] => ["foo", "bar"] Good enough. OK for 64 bits.
Whiteboard: (none) => MGA8-64-OKCC: (none) => tarazed25
Validating.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
CC: (none) => davidwhodginsKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2022-0164.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED