Valid gems with long dependency requirements cannot be pushed

[Fryguy]

This was a new one for me, but I wanted to limit my gem to specific versions of rack to avoid the most recent CVE there, while still allowing the latest of the 2.2, 3.0, or 3.1 y-streams (Since I don't know what callers will need which version of rack - I'm looking at you Rails 7.0).

Since there's no "OR" or "range" syntax for the gem requirements that I'm aware of, I built the following in my gemspec (It's gross, I know, I don't know what else to do 😆).

# Enforce a minimum of 2.2.13, 3.0.14, or 3.1.12 for CVE-2025-27610
spec.add_runtime_dependency "rack", ">= 2.2.13", *("!= 3.0.0".."!= 3.0.9"), "!= 3.0.4.1",
  "!= 3.0.4.2", "!= 3.0.6.1", "!= 3.0.9.1", *("!= 3.0.10".."!= 3.0.13"), *("!= 3.1.0".."!= 3.1.9"),
  *("!= 3.1.10".."!= 3.1.11"), "< 4"

This is functionally equivalent to, but visually shorter than:

spec.add_runtime_dependency "rack", ">= 2.2.13", "!= 3.0.0", "!= 3.0.1", "!= 3.0.2",
  "!= 3.0.3", "!= 3.0.4", "!= 3.0.5", "!= 3.0.6", "!= 3.0.7", "!= 3.0.8", "!= 3.0.9", "!= 3.0.4.1",
  "!= 3.0.4.2", "!= 3.0.6.1", "!= 3.0.9.1", "!= 3.0.10", "!= 3.0.11", "!= 3.0.12", "!= 3.0.13",
  "!= 3.1.0", "!= 3.1.1", "!= 3.1.2", "!= 3.1.3", "!= 3.1.4", "!= 3.1.5", "!= 3.1.6", "!= 3.1.7",
  "!= 3.1.8", "!= 3.1.9", "!= 3.1.10", "!= 3.1.11", "< 4"

Everything works fine...bundler works fine, bundler references to this via git or path work fine (which is how I tested it), and gem build works fine. However, on gem push I get the error:

There was a problem saving your gem: Dependency requirements is too long (maximum is 255 characters)

Steps to Reproduce

1. See above and create a simple gemspec with the spec above, build it, and try to push it.

Expected Behavior

I didn't expect a valid gem to not be able to be pushed to rubygems.org. If there needs to be a length limit on the dependency requirements, that's understandable, however then I would have expected gem build to also fail with the same error (or at least give a warning). Conversely, it feels like anything that's buildable with gem build should be pushable to rubygems.org.

Current Behavior

gem push yields

There was a problem saving your gem: Dependency requirements is too long (maximum is 255 characters)

Possible Solution

I don't know the reason for the specific 255 character max limit, but maybe we can open that up a bit? I guess if you have to have a limit, then you can't make everyone happy, but perhaps 512 or 1024?

Additionally, a warning or straight up error on the rubygems build side would be helpful to avoid getting into this situation.

Alternatively, an OR syntax or a range syntax would help solve my particular situation because I wouldn't have to create this long list of individual fields to begin with.

Environment

Browser and its version:
RubyGems version: 3.5.22
Ruby: ruby 3.3.7 (2025-01-15 revision be31f993d7) [arm64-darwin23]

Additional Context

[simi]

Hello, I don't think gems should be the ones enforcing various specific gem dependency versions. That should happen in upstream (usually on app level to decide which exactly version to allow), otherwise dependency is deciding on which exact version is being used because of security reason. I don't expect my dependencies are going to handle this for me.

Anyway back to your report. Your gem is not passing requirement length validation. requirements is actually text column. We can indeed remove or extend this validation. Feel free to open PR to do so (or I can do for you). I'm also happy to do the opposite and warn during gem build (new policy will be needed in https://github.com/rubygems/rubygems/blob/master/lib/rubygems/specification_policy.rb, happy to help you with PR or I can open). There is no shared specification across gem servers how to process requirements column. gem build is independent of rubygems.org. Each gem server has own set of policies and validations.

Conversely, it feels like anything that's buildable with gem build should be pushable to rubygems.org.

That's wrong assumption. gem build has no direct contract with rubygems.org. You can build any gem locally (like rails gem), but you can't push it to rubygems.org since it needs additional ownership. Same gem can be published to any private repository. There is no way to find out gem server policy during gem build process. gem build is able to detect basic errors (preventing building gemspec) and common good practices with warnings (optional).

[Fryguy]

Thanks for those details @simi . I'll take a look into expanding that column definition.

That should happen in upstream (usually on app level to decide which exactly version to allow)

Agreed - this particular gem is a shared gem across all of our libraries and applications to centralize some of the common things, for example rubocop and our central definitions. Having to blast out PRs to 20 repos every time there's a CVE is cumbersome, so this was an attempt to mitigate that into a central location. In general, I agree with you, and I may have to move that way anyway for this particular problem.

[simi]

Great! @Fryguy feel free to ping me on Bundler Slack if you need help.