Fix 3 of the 4 Grype-blocking advisories (the 4th needs a Ruby upgrade)

[tas50]

Problem

The Grype scan job gates CI on high/critical findings and is failing on main and on every open PR. Four advisories block it:

Severity	Advisory	Package	Installed	Fixed in	Lockfiles
Critical	GHSA-xr9x-r78c-5hrm	activestorage	7.2.3.1	7.2.3.2	oc-id
High	GHSA-2x63-gw47-w4mm	websocket-driver	0.8.0	0.8.2	oc-id
High	GHSA-98m9-hrrm-r99r	faraday	2.14.1	2.14.3	oc-id and chef-server-ctl
High	GHSA-c4rq-3m3g-8wgx	nokogiri	1.18.9	1.19.3	oc-id

Because the gate trips on any high/critical in the tree, and each existing PR fixes only one advisory, #4239, #4177 and this PR were all failing the same check — none could go green alone. This PR fixes the first three.

Result: 1 critical + 3 high → 0 critical + 1 high.

Changes

activestorage isn't declared directly — it comes from the exact rails pin, so the pin moves to the patch release in the same series:

-gem 'rails', '7.2.3.1'
+gem 'rails', '7.2.3.2' # 7.2.3.2 fixes GHSA-xr9x-r78c-5hrm (ActiveStorage)

websocket-driver is transitive via actioncable (>= 0.6.1), so a direct floor moves it forward. Dependabot opened #4223 for it and closed it saying "Looks like websocket-driver is no longer a dependency" — that isn't right; it's still in the lock at line 747, still reachable through actioncable.

faraday needs the floor in both src/oc-id and src/chef-server-ctl — fixing only one still trips the gate. This duplicates #4239; the Gemfile.lock diffs here came out byte-identical to that PR's. Whichever lands first, the other can be dropped.

All floors follow the existing concurrent-ruby precedent — a bare floor rather than a SafeVersions constant, since there's no ruby_gems_cleanup.rb consumer for these gems and so nothing for SafeVersions to keep in sync.

The fourth advisory can't be fixed on the pinned Ruby

nokogiri is deliberately not addressed here:

nokogiri	required_ruby_version
1.18.9 (current)	>= 3.1, < 3.5
1.19.3 (the fix)	>= 3.2

omnibus_overrides.rb pins override :ruby, version: "3.1.7". Adding a >= 1.19.3 floor fails the resolve outright:

Bundler found conflicting requirements for the Ruby version:
  In Gemfile:
    nokogiri (>= 1.19.3) was resolved to 1.19.4, which depends on
      Ruby (>= 3.2)
  Current Ruby version:
    Ruby (= 3.1.7)

So GHSA-c4rq-3m3g-8wgx needs a Ruby 3.2+ upgrade first, which is far outside a dependency bump. Until then the Grype gate cannot reach zero.

This also explains #4177: it edits gem 'nokogiri', '1.18.9', platforms: :ruby, a line that no longer exists on main (removed by #4189) — hence the conflict — and the version it moves to could not resolve on Ruby 3.1 anyway. Worth closing.

Separately, #4189 dropping that line also dropped its platforms: :ruby guard ("Force Ruby platform to avoid glibc compatibility issues" from #4043), so the lock now resolves the precompiled x86_64-linux variant while omnibus_overrides.rb still pins override :nokogiri, version: "1.18.9". That may be worth a look on its own.

About the three extra gems in the oc-id lock diff

The lock also moves globalid 1.3.0 → 1.4.0, jbuilder 2.14.1 → 2.15.1, responders 3.2.0 → 3.2.1.

Not incidental staleness — I checked: a plain re-resolve of main's Gemfile is byte-identical to the committed lock. They move because they depend on the Rails subtree, and re-resolving it lets them float to the newest version their existing requirements already allow. The same three move under bundle lock, --update --conservative and --conservative --strict alike. Happy to pin them back if you'd rather hold them.

Verification

• Both locks regenerated with bundler 2.3.27 on ruby 3.1.7 under linux/amd64, matching the BUNDLED WITH and x86_64-linux platform already recorded. PLATFORMS, BUNDLED WITH and the rack/rexml/net-imap floors in DEPENDENCIES are unchanged in both.
• Re-running the resolve reproduces each lock byte for byte.
• Grype run over the whole tree exactly as CI does (dir:. --only-fixed): before 1 critical + 3 high, after 0 critical + 1 high (the nokogiri finding above).

Caveat

oc-id is a Rails app and I could not run its suite here, so the Rails patch bump and the three transitive bumps are unvalidated beyond dependency resolution. Worth a green test run before merge.