Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

VEX gemspec product detection reads commented-out `# spec.name =` / `# spec.version =` lines, so the document names the wrong product or version

Open Beginner friendly
  • Is something wrong?
#1,573 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
70/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
ruby, rust
Domain
security

Research direction

The gemspec parser is parse_gemspec in crates/socket-patch-core/src/vex/product.rs (lines ~363-380), and probe 9 is documented in vex.rs around line 66. Read the literal closure first, then run the two repro gemspecs from the issue through it to confirm the commented # spec.version = and # spec.name = lines are matched. Done means both files yield pkg:gem/acme with the computed version dropped, and a regression test covers the commented-line case.

Written by the indexing model from the issue text.

Description

agent:triaged bug bughunt pm:bundler priority:p1

[agent] Found by the scheduled Bundler (RubyGems) bug-hunt routine (ledger #316).

Summary

vex (and scan/apply/vendor --vex without --vex-product) names the top-level product of a gem library project from its root *.gemspec (parse_gemspec, probe 9). The parser takes the first line whose =-left side ends in .name / .version and whose right side starts with a quote. It never skips Ruby comments, so a commented-out assignment wins over the live one:

  • # spec.version = "0.0.1" above spec.version = Acme::VERSION → product pkg:gem/[email protected] (the real version is 2.3.4; a computed version should be dropped, giving pkg:gem/acme).
  • # spec.name = "acme-legacy" above spec.name = "acme" → product pkg:gem/acme-legacy.

No warning is printed. Ruby (Gem::Specification.load) gives acme-2.3.4 for both files.

Impact

The OpenVEX document's products[].@id names a product or version that doesn't exist, so consumers that match VEX statements to their SBOM by product purl won't apply them (or will apply them to the wrong release). The run reports success. Leaving old assignments commented out is a common edit when a gem moves its version into a VERSION constant, or after a gem is renamed.

Repro (Linux, Ruby 3.3.6, Bundler 2.5.22 / 4.0.18; main e76cb9b)

mkdir -p acme/lib/acme && cd acme
echo 'module Acme; VERSION = "2.3.4"; end' > lib/acme/version.rb
cat > acme.gemspec <<'E'
require_relative "lib/acme/version"
Gem::Specification.new do |spec|
  spec.name = "acme"
  # spec.version = "0.0.1" # pinned before the VERSION constant existed
  spec.version = Acme::VERSION
  spec.authors = ["x"]
  spec.summary = "x"
  spec.files = []
  spec.add_dependency "colorize", "0.8.1"
end
E
printf 'source "https://rubygems.org"\ngemspec\n' > Gemfile
bundle install
# any applied gem patch in .socket/manifest.json (hand-written [email protected] manifest + `apply --offline` here)
socket-patch apply --offline
socket-patch vex | grep '"@id": "pkg:gem/acme'
#   "@id": "pkg:gem/[email protected]"
ruby -e 'puts Gem::Specification.load("acme.gemspec").full_name'
#   acme-2.3.4

The name variant: put # spec.name = "acme-legacy" above Gem::Specification.new (and drop the commented version). vex then gives "@id": "pkg:gem/acme-legacy". Each shape reproduced twice.

Expected vs actual

  • Expected: parse_gemspec's own doc says the product comes "from literal <spec>.name = "…" / <spec>.version = "…" assignments; a version computed from a constant (Foo::VERSION) is dropped" (crates/socket-patch-core/src/vex/product.rs:363-366). A comment is not an assignment, so this file should give pkg:gem/acme (version dropped). vex.rs:66 documents probe 9 as pkg:gem/<name>[@<version>].
  • Actual: pkg:gem/[email protected] / pkg:gem/acme-legacy.

Matrix

OS Ruby / Bundler Commented version Commented name
Linux (sandbox) 3.3.6 / 2.5.22 reproduces (×2) reproduces (×2)

The parser is OS- and Bundler-independent (pure text), so macOS / Windows aren't probed.

Suspect code

crates/socket-patch-core/src/vex/product.rs:367-380: the literal closure trims the line and checks lhs.ends_with(".name") without first dropping lines that start with # (or text after a # outside a string). =begin/=end blocks and heredocs are also read as code, though those are rarer.

First bad version: not bisected (the sandbox clone is shallow). parse_gemspec has had this shape since gemspec detection was added.

Dominant language
Rust
Stars
8
Forks
1
Avg merge
16h 35m
Merged PRs (30d)
574

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SocketDev/socket-patch

All issues in SocketDev/socket-patch

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.