Skip to content

fix(vendor): vendor pure-ruby (?platform=ruby) gems, gate on the purl not the staging dir - #172

Merged
Mikola Lysenko (mikolalysenko) merged 3 commits into
mainfrom
fix/gem-platform-ruby-vendorable
Aug 15, 2026
Merged

fix(vendor): vendor pure-ruby (?platform=ruby) gems, gate on the purl not the staging dir#172
Mikola Lysenko (mikolalysenko) merged 3 commits into
mainfrom
fix/gem-platform-ruby-vendorable

Conversation

@mikolalysenko

@mikolalysenko Mikola Lysenko (mikolalysenko) commented Aug 13, 2026

Copy link
Copy Markdown
Collaborator

Problem

Vendoring a pure-ruby gem whose production patch purl is platform-qualified — pkg:gem/activestorage@7.0.2.2?platform=ruby — was refused with platform_gem_unsupported ("installed dir gem does not equal activestorage-7.0.2.2"). The ruby platform is the DEFAULT, portable RubyGems platform, not a native build, so this refusal is wrong.

The gem vendor gate used installed_dir.file_name() != "<name>-<version>" as a proxy for "platform-specific build". That proxy breaks on the registry auto-fetch ladder: a lockfile-resolvable-but-not-installed gem is staged into a private tempdir named literally gem (registry_fetch::fetch_gem), so dir_name is gem and every pure-ruby auto-fetched gem tripped the gate.

What #157 already fixed vs. what remained (verified against current main, real production API + rubygems.org, SOCKET_NO_CONFIG=true):

Fix

Gate on the authoritative signal — the purl's own ?platform= qualifier — instead of the staging dir name:

  • ?platform=ruby (and a bare, unqualified purl) is the portable build and vendors normally.
  • Only a genuine native platform (x86_64-linux, arm64-darwin, java, x64-mingw32, …) is refused, with the same clear platform_gem_unsupported code.
  • Defense in depth: a locally-resolved platform-suffixed install dir (<name>-<version>-<suffix>) is still refused (preserving the downstream invariant that platform installs never reach the copy/lock edit). The auto-fetch gem dir is not such a suffix, so it passes.

Adds a small reusable purl_qualifier(purl, key) to utils::purl (the other ecosystems only ever strip qualifiers) rather than hand-rolling the parse. Change is scoped to the gem vendor path.

Test

  • New hermetic unit tests in the gem vendor module (RED before / GREEN after — both fail on the old gate, the first reproducing the exact installed dir gem does not equal rack-3.2.6 symptom):
    • test_platform_ruby_gem_from_autofetch_staging_dir_vendors — a ?platform=ruby gem from a gem-named auto-fetch staging dir now vendors successfully.
    • test_refuses_native_platform_qualifier — a native ?platform=x86_64-linux purl is still refused even from a clean leaf dir.
    • test_refuses_platform_suffixed_dir (existing) stays green via the defense-in-depth dir check.
    • test_purl_qualifier — unit coverage for the new helper.
  • Real end-to-end (rebuilt binary, SOCKET_NO_CONFIG=true, live prod + rubygems.org):
    • The previously-broken auto-fetch scenario now vendors cleanly 4/4 runs (applied: 1, exit 0), via vendor_fetched_missingvendor_prebuilt_downloaded.
    • Installed-gem scenario still clean 8/8.
    • Delivery proof: a cold, frozen bundle install from the committed .socket/vendor/ tree succeeds (exit 0) and bundle info activestorage resolves 7.0.2.2 from the vendored (patched) path.
  • cargo build + cargo clippy (both crates) clean; the only clippy warnings are pre-existing doc_lazy_continuation in e2e_vendored_production.rs (untouched).

Note (separate, pre-existing, out of scope): with the default --vendor-source auto/service, the patch-service gem-stub-gemspec for activestorage omits s.summary, which RubyGems' validation rejects on bundle install. This is a converter/service-side artifact defect, not in the gem vendor CLI path — it affects the installed and auto-fetch paths equally and was simply never reached before because vendoring failed first. Delivery via the local-build stub (a valid gemspec) works, as shown above. The live-ignored gem_bundler_vendored_known_platform_defect e2e leg will now take its built-in "vendor succeeds" branch; promoting it to a full frozen-install delivery proof is a follow-up gated on that stub-summary fix.

🤖 Generated with Claude Code


Note

Medium Risk
Changes gem vendor gating logic on production patch paths; scope is limited to platform detection with added tests, but incorrect classification could still allow or block vendoring incorrectly.

Overview
Fixes incorrect platform_gem_unsupported refusals for pure-ruby gems whose patch PURL is ?platform=ruby (or unqualified), especially on the registry auto-fetch path where content is staged in a tempdir named gem rather than <name>-<version>.

Adds purl_qualifier in utils/purl to read qualifier values (case-insensitive keys, stops at #subpath). Gem vendor logic now treats ?platform=ruby and bare purls as portable and vendors them; only non-empty, non-ruby platform values (e.g. x86_64-linux) are refused via platform_gem_unsupported.

Defense in depth: platform-suffixed install dirs (<name>-<version>-<suffix>) are still refused via dir_name.starts_with("{leaf}-") instead of dir_name != leaf, so the literal gem staging dir is not mistaken for a native build.

New unit tests cover purl_qualifier, native platform refusal from a clean leaf dir, and the auto-fetch gem staging regression.

Reviewed by Cursor Bugbot for commit ed3688f. Configure here.

@Tanmay182003 Tanmay Singla (Tanmay182003) left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

crates/socket-patch-core/src/vendor/gem.rs:215 — maybe allowlist?

if dir_name != leaf && dir_name != "gem" {

Only the two legitimate names pass (<name>-<version> when installed, gem when staged by registry_fetch::fetch_gem), so an unexpected dir still fails closed. The current suffix check admits any other name. Non-blocking.

… not the staging dir

The gem vendor gate refused any install whose dir name was not
`<name>-<version>`, using that as a proxy for "platform-specific build".
That proxy is wrong for the registry auto-fetch ladder: a lockfile-
resolvable-but-not-installed gem is staged into a private tempdir named
literally `gem` (registry_fetch::fetch_gem), so a pure-ruby gem like
`activestorage` (whose production patch purl is `?platform=ruby`, the
DEFAULT portable platform) was refused with `platform_gem_unsupported`.

gems the crawler finds installed (qualified `?platform=ruby` now maps to
the installed base dir), so `scan --mode vendored` vendors cleanly when the
gem is installed under `vendor/bundle` or a gem home. But the auto-fetch
path (fresh clone / uninstalled but lock-resolvable) still hit the bug with
the identical error.

Gate on the authoritative signal instead: the purl's own `?platform=`
qualifier. `ruby` (and a bare, unqualified purl) is the portable build and
vendors; only a genuine native platform (`x86_64-linux`, `arm64-darwin`,
`java`, `x64-mingw32`, …) is refused. A defense-in-depth dir check still
refuses a locally-resolved platform-suffixed install dir
(`<name>-<version>-<suffix>`), which the auto-fetch `gem` dir is not.

Adds a reusable `purl_qualifier(purl, key)` to utils::purl (the other
ecosystems only ever strip qualifiers) and hermetic regression tests:
`?platform=ruby` from a `gem`-named staging dir now vendors; a native
`?platform=x86_64-linux` is refused even from a clean leaf dir.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Per review (Tanmay182003): the defense-in-depth install-dir check was a
suffix match (`dir_name != leaf && dir_name.starts_with("{leaf}-")`), which
refuses `<name>-<version>-<platform>` builds but ADMITS any other unexpected
dir name. Switch to an allowlist — only the two legitimate names pass: the
installed `<name>-<version>` leaf and the literal `gem` staging dir from the
registry auto-fetch ladder (registry_fetch::fetch_gem). Everything else fails
closed. Generalize the refusal message accordingly (kept errorCode
platform_gem_unsupported); update the one dir-check assertion that keyed on
the old "platform-suffixed" wording to "platform-specific", and add
test_refuses_unexpected_install_dir_name (a `random-unrelated` dir the old
suffix check would have admitted is now refused).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The pinned gem patch activestorage@7.0.2.2 (2535d43d) was intentionally
unpublished 2026-08-14 pending a corrected republish. Its record still
resolves via /patch/view/<uuid>, but the discovery endpoints
(/patch/batch, /patch/by-package) now return zero patches for it, so
preflight_required_patches_are_published, the advisory canary, and the
gem redirect leg fail for reasons unrelated to the CLI — red-lighting the
required hosted-e2e check on every PR and on main.

Add a single GEM_E2E_DISABLED switch (defaulting true) that skips those
three gem legs while keeping npm/PyPI/cargo enforced. The gem redirect
leg returns unconditionally (NOT soft_skip!, which panics under STRICT),
so it skips cleanly in CI too. Flip the const back to false (and re-point
GEM_UUID if the replacement differs) once the corrected patch is live.

Verified under SOCKET_PATCH_HOSTED_E2E_STRICT=1 against real production:
preflight + canary pass on the three remaining ecosystems, the gem leg
prints SKIP and returns; 3 passed, 0 failed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@mikolalysenko
Mikola Lysenko (mikolalysenko) merged commit e64fb54 into main Aug 15, 2026
62 checks passed
@mikolalysenko
Mikola Lysenko (mikolalysenko) deleted the fix/gem-platform-ruby-vendorable branch August 15, 2026 01:38
Mikola Lysenko (mikolalysenko) added a commit that referenced this pull request Aug 19, 2026
…ish (#217)

Production republished the rubygems patch catalog on 2026-08-18: 15 free
activestorage patches (5.2.0-6.0.3, GHSA-m42x-37p3-fv5w / CVE-2020-8162).
The old pin activestorage@7.0.2.2 (2535d43d-…) no longer exists, and the
hosted registry's compact index now serves the full dependency list — the
server defect that motivated the temporary gem shutdown is fixed.

- e2e_hosted_production: delete the GEM_E2E_DISABLED kill switch (all 3
  sites) and the probe-based install tolerance per its own auto-retire
  design (gem_registry_base/http_probe helpers now dead, removed); re-pin
  to activestorage@6.0.3 / 15e960b5-…; the leg is renamed
  gem_bundler_hosted_install_proof and asserts the full chain
  unconditionally (redirect rewrite, CHECKSUMS pin swap to the patched
  sha, real install through patch.socket.dev, per-file afterHash
  verification). Verified live: 3/3 green incl. preflight + canary.
- e2e_vendored_production: re-pin; the platform_gem_unsupported tolerance
  is vestigial (gap fixed in #172) and the leg's doc comment now says so.
  The full delivery-proof upgrade is deferred to a stacked fix PR: the
  served gem-stub-gemspec artifact is currently invalid (missing
  summary/authors; bundler rejects the path source — discovered
  2026-08-19). Verified live: preflight + gem leg green.
- e2e_gem: re-pin the 5.2.0 lifecycle tests to the republished patch
  (efc8d8ca-…, CVE-2020-8162); GEM_PURL now carries ?platform=ruby
  because `get` keys the manifest by the view response's qualified purl.
  Verified live: 3/3 green.
- in_process_vendor: new test pinning the qualified-purl
  (?platform=ruby) path through scan --vendor — the regression that
  would silently re-open the #172 gap (ledger keyed by qualified purl,
  basePurl bare).
- docs/testing/{hosted,vendored}-production-e2e.md: catalogs re-pinned,
  defect sections converted to FIXED-history style, new OPEN section for
  the invalid served stub gemspec.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Mikola Lysenko (mikolalysenko) added a commit that referenced this pull request Aug 19, 2026
…c is invalid (#221)

* test(gem): restore production e2e after the 2026-08-18 catalog republish

Production republished the rubygems patch catalog on 2026-08-18: 15 free
activestorage patches (5.2.0-6.0.3, GHSA-m42x-37p3-fv5w / CVE-2020-8162).
The old pin activestorage@7.0.2.2 (2535d43d-…) no longer exists, and the
hosted registry's compact index now serves the full dependency list — the
server defect that motivated the temporary gem shutdown is fixed.

- e2e_hosted_production: delete the GEM_E2E_DISABLED kill switch (all 3
  sites) and the probe-based install tolerance per its own auto-retire
  design (gem_registry_base/http_probe helpers now dead, removed); re-pin
  to activestorage@6.0.3 / 15e960b5-…; the leg is renamed
  gem_bundler_hosted_install_proof and asserts the full chain
  unconditionally (redirect rewrite, CHECKSUMS pin swap to the patched
  sha, real install through patch.socket.dev, per-file afterHash
  verification). Verified live: 3/3 green incl. preflight + canary.
- e2e_vendored_production: re-pin; the platform_gem_unsupported tolerance
  is vestigial (gap fixed in #172) and the leg's doc comment now says so.
  The full delivery-proof upgrade is deferred to a stacked fix PR: the
  served gem-stub-gemspec artifact is currently invalid (missing
  summary/authors; bundler rejects the path source — discovered
  2026-08-19). Verified live: preflight + gem leg green.
- e2e_gem: re-pin the 5.2.0 lifecycle tests to the republished patch
  (efc8d8ca-…, CVE-2020-8162); GEM_PURL now carries ?platform=ruby
  because `get` keys the manifest by the view response's qualified purl.
  Verified live: 3/3 green.
- in_process_vendor: new test pinning the qualified-purl
  (?platform=ruby) path through scan --vendor — the regression that
  would silently re-open the #172 gap (ledger keyed by qualified purl,
  basePurl bare).
- docs/testing/{hosted,vendored}-production-e2e.md: catalogs re-pinned,
  defect sections converted to FIXED-history style, new OPEN section for
  the invalid served stub gemspec.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* test(gem): adversarial-review hardening — self-adapting UUID pin, frozen converged-lock install proof, hermeticity

Round-2 fixes on the gem e2e restoration:

* hosted gem leg: GEM_UUIDS any-of set (PYPI_UUIDS precedent) — parse the
  UUID actually wired into the rewritten Gemfile's patch-registry URL,
  assert membership, and afterHash-verify against that exact patch's
  /patch/view; hard-assert the BUNDLE_PATH wipe; reinstall under
  BUNDLE_FROZEN=true with converged-lock assertions (patch-registry GEM
  remote + `activestorage (= 6.0.3)!` DEPENDENCIES pin), verified live
* mimemagic hazard: USE_FREEDESKTOP_PLACEHOLDER=true on every
  gem-installing leg in e2e_hosted_production.rs and e2e_gem.rs
* published_patch_advisory_counts: HTTP-status guard like its siblings
* truthing: qualifiers are normalized by the SERVER, nothing client-side
  strips (consts comments + hosted doc coverage row + vendored doc
  REPLACED-pin history keeping the withdrawn 7.0.2.2/2535d43d ids findable)
* e2e_redirect_gem_build.rs: module doc reframed historical, dangling
  is_known_defect pointer fixed to the docs history section
* e2e_gem.rs: GHSA-or-CVE advisory assertion, full SOCKET_* scrub +
  SOCKET_NO_CONFIG, assert_after_hashes delete-entry branch
* in_process_vendor.rs: qualified gem test at full parity with its bare
  twin (PATH remote, stub gemspec, downloaded==1, positive applied event),
  exact percent-encoded by-package mock paths, new detached-qualified
  revert test

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(vendor): fall back to local build when the served gem stub gemspec is invalid

Defense-in-depth for defect D4 from the 2026-08-19 gem live-matrix campaign
(verified 6/6 live across bundler 1.17/2.7/4.0): production's gem-stub-gemspec
secondary artifact omits the rubygems-required `summary` and `authors`
attributes (and `licenses`). The CLI sha512-verified the stub and wrote it
verbatim as the vendored path-source `<name>.gemspec`, and every bundler major
validates path-source gemspecs, so any post-vendor or fresh-checkout
`bundle install` exited 1 with `missing value for attribute summary`. A
depscan-side fix for the stub generator is in flight, but every
currently-published gem stub is invalid, so the CLI hardens now.

An INVALID served stub now follows the existing MISSING-stub policy, under its
own code (additive/MINOR):

- `--vendor-source auto`: loud `vendor_prebuilt_stub_invalid` warning naming
  the missing attributes, then fall back to the local build (installed gem +
  locally derived stub);
- `--vendor-source service` (explicit): refuse with
  `vendor_prebuilt_stub_invalid`, naming the attributes and the remedy, before
  anything is written (no partial artifacts).

Validation is a conservative textual heuristic (assignment-line presence for
`summary` / `authors`|`author`, obviously-empty spellings rejected — no ruby
parsing); a legitimate stub always passes and is still written byte-verbatim.
A missing `licenses` is only mentioned in the message (rubygems warns, not
fails). CLI_CONTRACT.md documents the new code in the fallback ladder and the
PatchAction vocabulary.

Tests:
- hermetic (wiremock, RED->GREEN): auto+invalid-stub falls back to the local
  build with the loud warning and the LOCAL stub on disk; service+invalid-stub
  refuses with `vendor_prebuilt_stub_invalid` leaving no partial artifacts and
  an untouched lock; the valid-stub byte-verbatim write is pinned (the
  service-success fixture now carries the required attributes); plus a unit
  table for the heuristic's spellings.
- live regression leg: `e2e_vendored_production.rs`'s gem leg is upgraded to
  `gem_bundler_vendored_install_proof` — a full fresh-dir frozen
  `bundle install` delivery proof with the failure tolerance and the
  `SOCKET_PATCH_VENDORED_E2E_GEM_STRICT` knob deleted. It passes against real
  production TODAY via the auto fallback (the served stub is still invalid),
  and exercises the service artifact directly once the depscan fix deploys and
  the artifacts rebuild. The leg installs in bundler's deployment layout
  (`vendor/bundle` inside the project) so the crawler-visible install can feed
  the local-build fallback its stub gemspec.

Verified live against production: scan --mode vendored applied=1 via the
fallback with the `vendor_prebuilt_stub_invalid` event, vendored gemspec
carries real summary/authors; --vendor-source service refuses with the new
code and leaves no .socket/vendor.

Stacked on #217 (test/gem-e2e-restore).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(vendor): review round — gem-home guard, empirical rubygems bar, both-arm stub validation, truthful dead-ends, on-disk heal

Adversarial-review fix round for the D4 stub-hardening PR.

SECURITY (1): the local-stub derivation walked two parents up from
installed_dir unconditionally. For a registry auto-fetch staging dir
(<private tempdir>/<name>-<version>) that escapes into the SHARED temp
root, making $TMPDIR/specifications/<leaf>.gemspec a predictable,
attacker-plantable path whose contents would be committed and eval'd as
Ruby by every later `bundle install`. The derivation now requires
installed_dir's parent to be a literal `gems/` dir (a real gem-home
layout); staging dirs have no local stub. Test plants a valid spec at
the old derivation target and proves it is never consumed.

Scanner rewrite (2): comment-stripping at `#` truncated inside string
literals (s.summary = "#1 Ruby web server" judged missing → valid stubs
refused under service). The scanner now examines raw lines anchored to
the line start (receiver ident + .attr + assignment), where a preceding
comment marker is impossible. The emptiness policy is now EMPIRICAL,
verified against rubygems 3.3/3.5/3.6 in the bundler 1.17/2.7/4.0 era
images: summary hard-fails only when never assigned (nil/"" are
writer-coerced, warning at most); authors hard-fails when never
assigned or collapsing to no String elements ([], nil, [nil], %w[] —
while [""] passes). The old code refused rubygems-tolerated stubs and
passed %w[] which hard-fails.

Both-arm validation (3): the local-build arm wrote the local stub
verbatim; it now validates at the same write choke point and refuses
`gem_spec_invalid` naming the file (new CLI_CONTRACT vocabulary row).
The GEMSPEC/GEMSPEC_318/GEMSPEC_PUMA and CLI-suite fixtures now carry
summary+authors like every healthy rubygems-written stub.

Truthful dead-end (4): auto + invalid served stub + gem not installed
used to refuse gem_spec_missing with circular advice ("use
--vendor-source=service" <-> service says "use auto") and the D4
diagnostic never reached the envelope (Refused carries no warnings).
The FallBack variant now carries the served-stub defect; the refusal is
`vendor_prebuilt_stub_invalid`, names the defect, and advises
installing the gem. Tests cover auto and service, both not-installed.

Heal existing victims (5): the idempotent hot path only checked the
vendored gemspec EXISTS, silently re-blessing pre-fix invalid stubs.
copy_ok now re-validates the on-disk stub; invalid routes into the
existing artifact-only rebuild (test: pre-seeded invalid stub on disk →
re-scan rewrites a valid one, pair edit + ledger untouched).

Dedupe (11 + addendum B): one shared attr_mention line-scanner under
both gemspec_declares_extensions and the attr checks; the miss closure
widened with the (hard code, remedy) pair instead of a re-implemented
branch; licenses/license alias fan-out folded into the alias-list
helper; stub_text bound once.

e2e leg robustness (6-10): bundler invocations scrub ambient
BUNDLE_*/GEM_*/RUBYOPT (sibling-suite pattern) and set
USE_FREEDESKTOP_PLACEHOLDER=true (mimemagic shared-mime-info hazard,
mirrors #217 round 2); delivery proof asserts canonicalized
starts_with(fresh-dir) provenance and compares installed bytes against
captured pristine bytes; a route-attribution assertion requires exactly
one of {vendor_prebuilt_downloaded, vendor_prebuilt_stub_invalid} so
the leg auto-retires the fallback expectation when the depscan stub fix
deploys; applied/failed/idempotency/revert assertions are scoped to the
activestorage purl so future catalog additions cannot red the leg;
stale doc comments fixed.

Contract (addendum A): documented why the service-mode refusal on an
invalid stub rides a MINOR — the prior exit-0 wrote a stub bundler
rejects (an uninstallable project); the refusal is the bug fix.

Rebased on test/gem-e2e-restore @ 63531d9 (PR #217 review round 2).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants