CHEF-37625 - Add concurrent-ruby version floor to chef-server-ctl Gemfile - #4231
Open
lbakerchef wants to merge 2 commits into
Open
CHEF-37625 - Add concurrent-ruby version floor to chef-server-ctl Gemfile#4231lbakerchef wants to merge 2 commits into
lbakerchef wants to merge 2 commits into
Conversation
lbakerchef
force-pushed
the
CHEF-37625/lbaker
branch
3 times, most recently
from
August 18, 2026 14:22
21181f3 to
1a09f74
Compare
Add an explicit concurrent-ruby version floor to src/chef-server-ctl/Gemfile. concurrent-ruby is a real (transitive, via chef/knife/berkshelf) dependency, currently resolving to 1.3.8 -- already above the floor, so this adds an explicit safety net rather than changing the resolved version. Three CVEs affect versions below 1.3.7 (GHSA-6wx8-w4f5-wwcr, GHSA-h8w8-99g7-qmvj [high], GHSA-wv3x-4vxv-whpp; Dependabot alerts 377, 380, 383), all agreeing on the same minimum patched version. Declared as a bare floor rather than routed through omnibus-config's safe_versions.rb/resolve_safe_version.call (unlike rack/rexml above): that mechanism exists to keep a cleanup-recipe threshold (ruby_gems_cleanup.rb) and a Gemfile floor from drifting apart for the same gem -- it is not a generic place to declare any gem's minimum version. CHEF-37625 is scoped only to Dependabot's Gemfile.lock scanning, which this floor alone fully and permanently resolves; there is no ticket or on-disk test/scan finding establishing a cleanup need for concurrent-ruby, so there is no second consumer for safe_versions.rb to keep in sync with this floor. See the companion documentation added to chef-server-omnibus-config's safe_versions.rb (same ticket) for the fuller explanation of when a constant belongs there vs. a bare Gemfile floor like this one. CHEF-37625 Signed-off-by: Lincoln Baker <51833247+lbakerchef@users.noreply.github.com>
…dant, oc-id, oc_bifrost pedant Signed-off-by: Lincoln Baker <51833247+lbakerchef@users.noreply.github.com>
lbakerchef
force-pushed
the
CHEF-37625/lbaker
branch
from
August 21, 2026 20:38
1a09f74 to
c4e2b40
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
NOTE
The oc-id verify failure is fixed here:
https://progresssoftware.atlassian.net/browse/CHEF-37669
Summary
Adds an explicit
concurrent-rubyversion floor (>= 1.3.7) directly tosrc/chef-server-ctl/Gemfile. concurrent-ruby is a real (transitive, via chef/knife/berkshelf) dependency, currently resolving to1.3.8— already above the floor, so this adds an explicit safety net rather than changing the resolved version.Declared as a bare floor rather than routed through the
SafeVersions/resolve_safe_version.callmechanism (unlike rack/rexml directly above it in the same file): that mechanism exists to keep a cleanup-recipe threshold (ruby_gems_cleanup.rb, inchef-server-omnibus-config) and a Gemfile floor from drifting apart for the same gem. concurrent-ruby has no on-disk cleanup consumer (no ticket or test/scan finding has established that need), so there's no second consumer for that mechanism to keep in sync — see the companionchef-server-omnibus-configPR (documentation-only, same ticket) for the fuller rationale.Jira
https://progresssoftware.atlassian.net/browse/CHEF-37625
CVEs closed
GHSA-6wx8-w4f5-wwcr, GHSA-h8w8-99g7-qmvj (high), GHSA-wv3x-4vxv-whpp (Dependabot alerts 377, 380, 383)
Stacked branch note
This PR is stacked on top of
CHEF-33469/lbaker(#4227, CHEF-35182 — the net-imap fix), which has not yet merged. As a result, this PR's diff currently includes #4227's commits in addition to this ticket's own change (theconcurrent-rubyfloor).Please review only the top commit (the
concurrent-rubyfloor addition) — the rest belongs to #4227 and is already under review there.Merge order matters for attribution, not final content: since this branch is a superset of #4227's tip, the end-state file content on
mainis identical regardless of which PR merges first. However, #4227 should merge first — merging this PR first would land #4227's still-unreviewed commits under this PR's merge event (bypassing #4227's own review), and with squash-merge could fold #4227's changes into this PR's squash commit instead of preserving #4227's own attribution.Testing
Verified via Docker (
ruby:3.1.3, bundler 2.3.27) with the real upstreamsafe_versions.rb(fromchef-server-omnibus-config, no concurrent-ruby constant) copied temporarily into place, mimicking the omnibus build's copy step: the resultingGemfile.lockis byte-identical to the pre-change lockfile — both the previousresolve_safe_version.call-indirected floor and this bare floor interpolate to the exact same>= 1.3.7requirement, so this is a zero-regression mechanism change. concurrent-ruby remains resolved at1.3.8. Fullchef-server-ctlrspec suite (79/0) previously verified against the functionally-equivalent indirected version; the bare-floor refactor produces no lockfile change, so no dependency resolution is affected.