bundle install should check checksums against committed file

When the user installs GitLab, and runs bundle install, the installed gems should be checked against Gemfile.checksums.lock file.

We should do this when

  • We install GitLab for a production instance
  • We run CI
  • We install gems in development

See https://gitlab.com/gitlab-com/gl-security/security-operations/sirt/operations/-/issues/2266

Note: bundler actively checks the downloaded gem's sha checksum against Rubygem.org (https://bundler.io/blog/2017/03/28/bundler-1-14-so-many-fixes.html#checksum-validation) but this is not enough.

Sequence

  1. For a new version of a gem, or a new gem, Developer adds checksums into committed file for that gem for all platforms from Rubygems.org
  2. On CI, two things happen:
    1. The committed file is checked against rubygems.org
    2. On bundle install:
      1. Gems are downloaded from rubygems.org
      2. The integrity of downloaded gems is checked against the committed file. (Downloaded gems can execute code as part of bundle install, hence it is important that this check is performed before the downloaded Gem can execute code.)
      3. If the integrity check passes, bundler continues with the installation.
      4. If the integrity check fails, bundler does not continue with the installation and fails.
  3. On other developer machines, and installations of GitLab:
    1. bundle install checks installed gems against the committed file as described under 2.2

Workaround

We can consider vendoring all our gems. This will sidestep any checksum issue

Links

Edited by Thong Kuah