rm Ruby 2.4 support to address rexml CVE #336
Conversation
jordannb
force-pushed
the
address-rexml-cve-via-rm-rb-2_4-support
branch
3 times, most recently
from
d54999f
to
30eda28
Compare
CHANGELOG.md
Outdated
| @@ -11,6 +11,7 @@ This project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.htm | |||
|
|
|||
| - Fixed a bug that overwrote existing self.extended method definitions. [[#324]](https://github.com/panorama-ed/memo_wise/pull/314) | |||
| - Fixed a bug that overwrote existing self.inherited method definitions. [[#325]](https://github.com/panorama-ed/memo_wise/pull/315) | |||
| - Removed Ruby 2.4 (EOL) support to allow upgrading rexml dependency version from a version that includes a [CVE](https://www.ruby-lang.org/en/news/2024/05/16/dos-rexml-cve-2024-35176/) [[#336]](https://github.com/panorama-ed/memo_wise/pull/336) | |||
|
|
|||
| _No breaking changes!_ | |||
There was a problem hiding this comment.
I think this is a breaking change, right?
There was a problem hiding this comment.
(See v0.2.0 in this file for formatting.)
There was a problem hiding this comment.
@JacobEvelyn Yes! I added the note here temporarily until I got the PR build working, and now with #317 merged, I believe it's working.
So now I have a question - We want to both remove support for 2.4, to remove "sub-dependency" on a CVE-containing gem, and we want to add support for 3.3 (possibly with YJIT benchmark). Typically, I wouldn't do those two things in the same PR, since they seem like different things. Is there a preferred way to include these changes in the same release but not the same PR?
There was a problem hiding this comment.
Sorry I missed this! I don't think we have a super defined process here so whatever form of "merge two PRs and at some point bump the VERSION constant" makes sense to you works for me. I think we can get these out in pretty quick succession so I'm not too worried. In one sense we wouldn't be adding support for 3.3 since the gem already works with 3.3, we'd just be adding CI tests/benchmarks for it. So if we wanted to be really thorough we could add 3.3 first in one PR, and then merge this PR with a VERSION bump?
Also, as a side note, I wasn't quickly able to get YJIT benchmarks working. I think it'll be a nice thing to have eventually but it wasn't even clear to me that the official ruby container can use YJIT so I wouldn't worry about that for now.
jordannb
force-pushed
the
address-rexml-cve-via-rm-rb-2_4-support
branch
from
30eda28
to
6274d0e
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #336 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 2 2
Lines 190 190
Branches 90 90
=========================================
Hits 190 190 ☔ View full report in Codecov by Sentry. |
jordannb
force-pushed
the
address-rexml-cve-via-rm-rb-2_4-support
branch
from
6274d0e
to
0d29bfd
Compare
jordannb
changed the title
jordannb
force-pushed
the
address-rexml-cve-via-rm-rb-2_4-support
branch
2 times, most recently
from
8c1fa32
to
189e44c
Compare
jordannb
force-pushed
the
address-rexml-cve-via-rm-rb-2_4-support
branch
from
189e44c
to
ae1a665
Compare
Before merging:
README.mdand update this PRCHANGELOG.md, add an entry following Keep a Changelog guidelines with semantic versioning