Upgrade rexml to 3.3.4 to address CVE-2024-39908, 41123, 41946

[raymzag]

This resolves CVE-2024-39908 : DoS in REXML and #5180

This vulnerability is showing up in bundle-audit.

Name: rexml
Version: 3.2.8
CVE: CVE-2024-39908
Criticality: Unknown
URL: https://github.com/ruby/rexml/security/advisories/GHSA-4xqq-m2hx-25v8
Title: DoS in REXML
Solution: upgrade to '>= 3.3.2'

Name: rexml
Version: 3.3.2
CVE: CVE-2024-41123
Criticality: Unknown
URL: https://www.ruby-lang.org/en/news/2024/08/01/dos-rexml-cve-2024-41123
Title: DoS vulnerabilities in REXML
Solution: upgrade to '>= 3.3.3'


Name: rexml
--
  | Version: 3.2.8
  | CVE: CVE-2024-41946
  | Criticality: Unknown
  | URL: https://www.ruby-lang.org/en/news/2024/08/01/dos-rexml-cve-2024-41946
  | Title: DoS vulnerabilities in REXML
  | Solution: upgrade to '>= 3.3.3'

Tests

bundle exec rake test:local

Finished in 36.30949 seconds.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
5981 tests, 80146 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
164.72 tests/s, 2207.30 assertions/s
Running RuboCop...
Inspecting 798 files
..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

798 files inspected, no offenses detected

ruby -Itest test/remote/gateways/remote_paypal_test.rb

Loaded suite test/remote/gateways/remote_paypal_test
Started
Finished in 97.803649 seconds.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
30 tests, 83 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This fails, but it seems to be failing on master branch anyway. Not sure if still active. https://www.mercurypay.com/ does not exist anymore.
ruby -Itest test/remote/gateways/remote_mercury_test.rb

[ozydingo]

I'm wondering why it has to be so tight? This will still prevent minor version upgrades, which generally shouldn't cause breakages. Would the following be suitable to pin to major version 3 while staging above the version required by the CVE?

Suggested change

	s.add_dependency('rexml', '~> 3.3.2')
	s.add_dependency('rexml', '~> 3.3', '>=3.3.2')

[raymzag]

Thanks updated.

[dan-jensen]

That solves the immediate problem, but doesn't prevent this scenario from happening again.

To help avoid this type of problem in the future, and to better align with the other add_dependency lines in the gemspec, I think we would prefer this:

s.add_dependency('rexml', '>= 3.3.2')

In other words, I don't think we have any reason for a pessimistic version constraint (meaning ~>) on rexml, because there doesn't seem to be any reason to believe future versions would break active_merchant.

For background, the original pessimistic constraint was added in eed45fe simply. There is no documented reason for a pessimistic constraint, so I think the version constraint was overly tight from the beginning. The gemspec declarations for activesupport, builder, and i18n do not have pessimistic constraints, which seems correct.

[damienjbyrne]

@dan-jensen Assuming that rexml is following semantic versioning correctly, wouldn't we want a conscious, verified step to any 4.0 version to check for breaking changes, however remote they may be? As such I think the suggestion from @ozydingo sets a sensible base and ceiling.

[dan-jensen]

@damienjbyrne you're right, it's definitely sensible. But there is a tradeoff. We can choose to prioritize breaking changes or vulnerabilities. Breaking changes tend to be obvious, and easy to resolve (simply don't change). Vulnerabilities tend to be non-obvious, and harder to resolve (because change is required). I think it makes sense to prioritize vulnerabilities, and flexibility in general, like the majority of this gemspec already does. But I didn't intend to cause a delay here. If there's doubt about flexible specifications, I support merging this PR now.

[emptyflask]

Merging this would be great, because after upgrading rexml to 3.3.2, activemerchant is currently forced back to 1.126.0

[dan-jensen]

@Heavyblade you seem to be a maintainer, would you have time to review & merge this? (Simple change, already with 2 community approvals.)

[emptyflask]

And now there's a another DoS vulnerability, CVE-2024-41123, requiring rexml 3.3.3.

[raymzag]

Removing this test is not the right way to fix the tests, but this was added 17 years ago and I don't think it's still relevant. trans_first gateway seems no longer active as well, even if I want to fix this, there would be no doc to refer to.

[n-studio]

We probably should remove Mercury and TransFirst completely in another PR.

[aenand]

Hi! these gateways are still active, you cannot remove them

[casperisfine]

I'm not a regular maintainer but got merge rights, and this is blocking for many people so I'll take the initiative to merge it.

[aenand]

@raymzag @casperisfine hello! this PR breaks the mercury gateway and it is still in use. Can you open a PR to fix it or revert this one?

[n-studio]

@aenand Do you have a link to mercury's documentation?

[aenand]

@aenand Do you have a link to mercury's documentation?

Unfortunately not. I did put up a PR to try and resolve the issue for their gateway so maybe that will suffice. We're syncing up internally tomorrow to see if it'll work

[dan-jensen]

I did put up a PR

This refers to #5206 in case anyone is looking.

[raymzag]

@aenand apologies I didn't fix the test properly. It was hard to tell they were in use. No website/docs, no recent commits in those gateways and remote tests have been failing in master don't know since when.

Thanks for putting up the fix.