Dependabot removes registry credentials from `Gemfile.lock`

[Lucas Mazza]

Is there an existing issue for this?

• I have searched the existing issues

Package ecosystem

Bundler

Package manager version

Bundler 2.5.x

Language version

Ruby 3.3.1

Manifest location and content before the Dependabot update

Gemfile

source "https://rubygems.org"

source "https://USERNAME:[e-mail]/" do
  gem "activesupport"
end

dependabot.yml content

version: 2
registries:
  secret-registry:
    type: rubygems-server
    url: https://rubygems.org
    username: USERNAME
    password: PASSWORD

updates:
  - package-ecosystem: "bundler"
    directory: "/"
    insecure-external-code-execution: "allow"
    versioning-strategy: "increase-if-necessary"
    schedule:
      interval: "daily"
    registries:
      - "secret-registry"

Updated dependency

No response

What you expected to see, versus what you actually saw

The Pull Request opened by Dependabot (lucasmazza/dependabot-registry-bug#1) shouldn't remove the USERNAME and PASSWORD from the Gemfile.lock.

We noticed this on a private repository with real credentials to a private RubyGems server, but the public repo mentioned here has the same behavior as our private app.

Native package manager behavior

bundle update activesupport produces the following diff:

diff --git a/Gemfile.lock b/Gemfile.lock
index 6b32d74..c580f09 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://USERNAME:[e-mail]/
   specs:
-    activesupport (7.1.3.3)
+    activesupport (7.1.3.4)
       base64
       bigdecimal
       concurrent-ruby (~> 1.0, >= 1.0.2)

Images of the diff or a link to the PR, issue, or logs

lucasmazza/dependabot-registry-bug#1

Smallest manifest that reproduces the issue

No response

[Lucas Mazza]

I found rubygems/rubygems#7560, and seeing that Dependabot was recently updated to use Bundler 2.5.11 I believe the issue here might be the mismatch with our local env/CI setup, just like the Heroku buildpack scenario described on the linked PR

[broksonic21]

Just chiming in that we use bundler 2.5.11 right now, so we want/depend on the behavior that dependabot is currently doing to use 2.5.11 as well and make sure the lockfile doesn't churn when it updates (before that update, it kept adding creds back in and flip-flopping the lock file whenever local devs ran bundle install using 2.5.11 (or 2.5.10)).

Until dependabot updated this week, we had to lock our bundler into an older version, but bumped it once dependabot did.

Ultimately, I think the real solution is that dependabot should use the version of bundler found in the Gemfile.lock file so it's consistent with how folks are setup (and perhaps offer PRs to update bundler itself as well). All of the scenarios I've seen in issues in dependabot-core and rubygems repo have been folks using older bundler versions against a 2.5.11+ created lockfile.

[Lucas Mazza]

We fixed this on our setup by updating Bundler on all of our envs and ensuring everyone was on 2.5.11

Ultimately, I think the real solution is that dependabot should use the version of bundler found in the Gemfile.lock file so it's consistent with how folks are setup

This would be great but I suspect very hard to achieve. In the meantime, any visibility on the package manager versioning and updates that Dependabot used would be helpful - not everyone knows that they can dig into this repo's history and try to troubleshoot their Pull Requests.

[David Rodríguez]

Hei! Sorry for the mess here 🙏, I didn't know so many people put credentials in their Gemfiles 😅.

I agree that ideally Dependabot should eventually respect the version of Bundler used by each application. But of course that needs to be implemented and it's not so easy. For example, Dependabot includes several monkeypatches to Bundler, so they should be functional in all Bundler versions, which seems ... hard, and hard to maintain. I hope to gradually support Dependabot use case better upstream, so that these monkeypatches can be removed and Dependabot can eventually respect the version of Bundler used by each application.

That all said, this change was too disruptive so I'm working on partially rolling it back in the next release.

I recommend that you fix this by "accepting the change", letting those credentials be removed and ensuring a modern enough Bundler version in all your environments that keeps "credential-less lockfiles". But if for whatever reason you can't do that at the moment, next Bundler version will keep the lockfile credentials if they are already there.