Gem with empty checksum throwing `undefined method match? for nil`

[jeffwidman]

I'm seeing an unexpected undefined method match? for nil error on a gem that is missing a checksum.

I'm not sure of the desired behavior, but the current state isn't helpful to end users.

I asked AI to summarize what I found.

Bundler should tolerate empty compact-index checksum metadata without crashing

Summary

Bundler/RubyGems can crash while parsing compact-index metadata when a gem version line contains an empty checksum value.

Observed error:

There was an error parsing the metadata for the gem <name> (<version>): NoMethodError
undefined method `match?' for nil
The metadata was [["checksum", []]]

I understand this originates from malformed registry metadata. The request here is for parser hardening: malformed empty/value-less checksum metadata should not raise an internal NoMethodError that aborts resolution.

Why this matters

A single malformed historical version in a source can block unrelated updates, because dependency resolution may inspect historical compact-index metadata even when the project depends on a newer version.

Environment

• Ruby: 3.3.10
• Bundler: 2.5.22
• RubyGems: 4.0.15
• Source type: compact index (/versions + /info/<gem>)

Reproduced locally with both Bundler 2 and Bundler 4

I created a minimal Gemfile that only references packageX 3.4.0 from a compact-index source and ran bundle lock --verbose with explicit versions.

• bundle _2.5.22_ lock --verbose -> reproduces undefined method match? for nil while parsing packageX (2.0.1) metadata.
• bundle _4.0.15_ lock --verbose -> reproduces the same error.

So this is reproducible in both Bundler 2.5.22 and Bundler 4.0.15 in this environment.

Problematic metadata shapes

These shapes should be treated defensively:

2.0.1 |checksum:

And parser-emitted tuples equivalent to:

[["checksum", []]]
[["checksum"]]
[["checksum", nil]]

Expected behavior (tentative)

I am not fully sure what the ideal resolver behavior should be for malformed compact-index metadata.

That said, an internal error like undefined method match? for nil is not very actionable for end users.

At minimum, one of these would be much easier to work with:

1. Treat empty/value-less checksum metadata as absent and continue resolution.
2. Raise a clear, user-facing parse/validation error that points to invalid compact-index checksum metadata for a specific gem/version.
3. Keep strict behavior for malformed non-empty checksum values (i.e., still raise a normal explicit error there).

Actual behavior

Resolver raises internal NoMethodError during metadata parsing, wrapped as Bundler::GemspecError, and update resolution aborts.

High-level repro

1. Use a compact-index source with at least one version line containing an empty checksum.
2. Run a dependency resolution command that touches metadata for that gem.
3. Observe parse failure with undefined method match? for nil.

Notes from downstream workaround

Dependabot implemented a defensive workaround for Bundler 4 helper paths by filtering nil/empty metadata entries before Bundler parses them, while preserving failures for malformed non-empty checksums.

Public reference:

• Bundler: tolerate empty registry checksum metadata in v4 helper dependabot/dependabot-core#15359

That workaround includes tests for:

• empty array checksum
• value-less checksum entry
• nil/blank metadata values
• malformed non-empty checksum still raising

Those test cases may be useful as upstream acceptance criteria.

Known status checked before filing

• I did not find an obvious matching open issue in rubygems/rubygems via repository issue search for combinations of:
  • checksum + compact index
  • Bundler::GemspecError + checksum
  • match? for nil
• I also reviewed recent RubyGems changelog entries and did not find an explicit fix note for this empty-checksum compact-index parsing case.

If this is already fixed on main or tracked elsewhere, I am happy to link and close.

[jeffwidman]

Also, this may be an issue with the GitHub Package Registry, which is where I'm observing this behavior... if it should be returning something else for an empty checksum... for example, omitting the key field entirely 🤷 ... then please let me know what expected behavior is for registries so I can fix that internally.

[jeffwidman]

Gentle nudge on this one... I'm happy to contribute a PR if you can clarify the expected behavior.