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
- 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
- On CI, two things happen:
- The committed file is checked against rubygems.org
- On
bundle install:- Gems are downloaded from rubygems.org
- 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.) - If the integrity check passes, bundler continues with the installation.
- If the integrity check fails, bundler does not continue with the installation and fails.
- On other developer machines, and installations of GitLab:
-
bundle installchecks 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
- Some relevant scripts are drafted in https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/2430
- An upstream proposal is discussed in https://github.com/rubygems/rfcs/issues/39. We can consider working with upstream when we have a solution
- I (@tkuah) opened an upstream PR in https://github.com/rubygems/rubygems/pull/5808
- How to write a Bundler plugin
- https://github.com/bbhoss/bundler/commit/7dd7e49f0d831c804b1db9aa3a0459f43387efa7 Previous spike from Bundler contributor
Edited by Thong Kuah