Cooldown option for bundle update and bundle outdated

[mudge]

@woodruffw’s “We should all be using dependency cooldowns” makes a good case that supporting a cooldown (a window of time between when a dependency is published and when it’s considered suitable for use) when updating dependencies is an effective way to mitigate common supply chain attacks.

npm-check-update supports this natively via its cooldown option, pnpm via its minimumReleaseAge, and Dependabot via cooldown.

Could Bundler support this directly itself when calling the likes of bundle update and bundle outdated?

At the moment, it seems Dependabot separately queries the RubyGems (and private registries’) API to determine the release date for each gem version so I assume this isn’t already readily available via a CLI command.

[hsbt]

Could Bundler support this directly itself when calling the likes of bundle update and bundle outdated?

👋 I'm positive to add this proposal to rubygems and bundler. I think it should be in the settings rather than options like pnpm, what do you think?

FYI: https://docs.renovatebot.com/key-concepts/minimum-release-age/

[mudge]

Would that make it simpler for the cooldown to apply to all applicable commands (rather than having to add a command line flag to individual commands)? If so, and especially if it can be controlled by an equivalent environment variable, that would work for my use case (automatically running bundle update in a scheduled workflow to regularly raise dependency updates).

[hsbt]

I wrote the current my thought for "cooldown" feature: https://dev.to/hsbt/should-rubygemsbundler-have-a-cooldown-feature-40cp

[Edouard-chin]

Thanks for the write up 🙌, I didn't get the chance to catch up this topic yet, so this is very useful.

I like this idea of having a block option in the Gemfile to specify a cooldown for some gems. It make things easy to ensure that every developers working on a codebase will get the cooldown respected whenever they bump a gem, regardless if they forgot to type --cooldown or don't have the right bundler config. Similarly, it makes it easy for external tools to download the Gemfile/Gemfile.lock (à la Dependabot) and respect the application cooldown choice.

The CLI option or Bundler config is probably useful for small teams or individual developers, but it will be hard to use at the enterprise level when every developers have different bundler config.

[tilo]

Respectfully, I think cooldowns are beside the point. The real problem isn't the frequency of gem releases — frequent updates are actually a good thing, since they often carry important bug fixes. The real problem is account takeovers and unauthorized releases.

2FA on release/upload or Trusted Publishing already exist, and directly prevent the attack itself, rather than just limiting the damage.

A more effective solution would be to enforce 2FA at the moment of publishing — for example, requiring a second factor when running rake release or gem push. This way, even if someone's credentials are compromised, they can't push a malicious release without also controlling the maintainer's second factor.

Beyond that, 2FA should be mandatory for all RubyGems accounts, not just top gems. The typosquatting attacks mentioned in this article targeted obscure gems precisely because they're less protected — so the long tail is where enforcement matters most.

an additional angle might be to try to scan new gems as soon as they’re uploaded — but a mandatory delay, whether in Bundler or on the server, would do more harm than good.

Opt-in cooldowns are a workaround for a policy gap — if RubyGems enforced 2FA or Trusted Publishing for all gems, new malicious pushes would be blocked at the source. Combined with ongoing scanning to clear out existing bad gems, cooldowns would eventually become unnecessary.

What would it take for RubyGems to make 2FA or Trusted Publishing mandatory for all gem publishers?

[radanskoric]

This is a great proposal and definitely something that should be adopted, but I don't think that is the whole solution:

1. It doesn't address typo squatting or the gem owner having malicious intent (very unlikely on well know gems but possible on obscure small gems).
2. It's possible for maintainers to make a mistake and merge a malicious change unknowingly. (due to being tired or any of the other reasons for human fallibility).

Basically I think that what you propose is definitely part of solution, but the story after publishing also needs improvement and I agree that cooldowns are not the full solution.

[radanskoric]

Building on the article's comment about how the actual value is allowing time for gems to be scanned, I'm wondering if a different mechanism than passage of time would be better. What if security firms and researchers could sign a release as vetted?

The mechanism would allow anyone to sign a release as vetted: another developer or a security company can sign the release after they've done their checks (automated or manual). Everyone else can declare who's signatures they want to wait for before installing. A lot of people might opt to wait for Maicej's Diffend signature before installing. Others might decide they trust their circle of developers they personally know and if any of them sign it, they will proceed to install.

Basically, the idea would be to shift from: "Wait a week and hope that someone will check it.".
To: "Wait until someone from the list of sources I trust has confirmed they checked it."

We might have a small default list of security signers vetted by the RubyGems team so everyone has a core list to start with. If someone wants faster checks, they can add their own trusted sources to their personal list. A large company might use their own security team. Once their signing directly on RubyGems for their own benefit, anyone else can decide to also add them to their trusted list. It might even provide a beneficial incentive to security firms to dedicate resources to becoming a well known source of security signatures, as a marketing avenue for their primary services.