Default strategy prevents proxied gems upgrades

[fauno]

I recently upgraded our geminabox instance from 1.2.0 to 1.4.1 and discovered the strategy change made on 54f7343 because bundle audit was telling me to upgrade to rails >= 6.4.1.7, but our repo only had up to 6.1.4.6.

I understand the previous strategy makes geminabox more secure, but it also prevents proxy instances to get upstream upgrades, specially if they were upgrading from a pre 1.3.0 geminabox version like us.

[fauno]

I'm discussing a proposal with my coworkers :)

[conathan]

From #345 (comment), they mentioned that you can get similar to the old behavior by using: Geminabox.rubygems_proxy_merge_strategy = :combine_local_and_remote_gem_versions

[catdevnull]

@conathan This would revert to the old (insecure) strategy :/

[fauno]

Since in our case we want to keep the proxy+local cache strategy, we think a better strategy would be to actually keep track of which gems are local. It would work like this:

• Gems pushed with gem inabox ... are considered local;
• Gems pulled but never pushed are considered remote;
• Geminabox never proxies a local gem;

This way:

• Proxy+cache keeps updating remote gems;
• Local gems are never confused with remote gems;
• If you fork a gem but keep the same name, once you push it, it starts taking precedence over remote versions;

If you think this is a good idea, we can work on a pull request :)

[conathan]

In our case, we are only using it as a cacheing mirror (and our actual setup is with adding the patch at #353, and using Geminabox.rubygems_proxy_merge_strategy = :remote_gems_take_precedence_over_local_gems.

• No local gems, other then what geminabox has cached

(Should probably mention, personally unaware of security implications of combine_local_and_remote_gem_versions, but haven't been trying to use the same geminabox instance for local and remote gems [we use one geminabox for our local gems [default merge strategy], another for rubygems [remote_gems_take_precidence], and a 3rd for cincgems [remote_gems_take_precidence]).

But felt like mentioning the 353 pull request was getting off topic for what was mentioned here, so opted to mention the combine_local_and_remote_gem_versions instead (which is currently in the codebase)

• Speaking of, a gotcha we ran into, was this patch 404's on the info links when using the combined merge strategy, where we switched to remote_gems_take precidence (makes sense looking at the patch). But in this case remote gems on merge strategy matched our setup nicely

[github-actions]

Could you update this issue?

[seandilda]

@conathan This would revert to the old (insecure) strategy :/

The old version is only insecure if you're using the same instance as a caching proxy AND adding local gems. I think the true fix is that geminabox should stop supporting the combined usage. It should have to choose between :local_gem_server mode or :caching_proxy mode. The security issues come when you try to support both at once.

[skaes]

The security issues come when you try to support both at once.

Security problems are still there, even if you have separate gem servers, because you would have to make sure every Gemfile in your company specifies for each in-house gem the correct server to pull from. This becomes increasingly tedious if you start building gems the depend on other gems. Last time I looked, bundler did not allow to specify gem server priorities.

@seandilda @fauno please check out the pending PR #435. It reduces the problem of preventing gem upgrades to the situation where you have uploaded a version of a public gem to your server that differs from all the publicly available gems.

[fauno]

@seandilda @fauno please check out the pending PR #435. It reduces the problem of preventing gem upgrades to the situation where you have uploaded a version of a public gem to your server that differs from all the publicly available gems.

hi! thanks! you're refering to a8ff740 right? at first i thought it wouldn't work for us because we push binary gems (using gem-compiler) from source-only gems available on rubygems (and sometimes patched versions, but mostly binary gems without changes). but i see you try to check if it exists remotely, and since they won't, the upload would be allowed, correct?

[skaes]

but i see you try to check if it exists remotely, and since they won't, the upload would be allowed, correct?

I would assume that for binary gems the SHA256 sum of the file content differs from all versions on rubygems.

So I guess the answer is no.

BTW, from a security point of view this is no different than uploading a version increment of a pure Ruby gem.

We are running a standalone server at the moment. The most basic strategy we use is to temporarily add rubgygems.org
as a bundler source, run bundle update and then sync our local gem cache with our server (we use a simple shell script using curl for that).

[github-actions]

Could you update this issue?