diff options
Diffstat (limited to 'doc/development/gemfile.md')
| -rw-r--r-- | doc/development/gemfile.md | 23 |
1 files changed, 20 insertions, 3 deletions
diff --git a/doc/development/gemfile.md b/doc/development/gemfile.md index f9cf69020bb..87304a761ea 100644 --- a/doc/development/gemfile.md +++ b/doc/development/gemfile.md @@ -4,7 +4,7 @@ group: unassigned info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -# `Gemfile` guidelines +# Gemfile guidelines When adding a new entry to `Gemfile` or upgrading an existing dependency pay attention to the following rules. @@ -15,6 +15,23 @@ We do not allow gems that are fetched from Git repositories. All gems have to be available in the RubyGems index. We want to minimize external build dependencies and build times. +## Request an Appsec review + +When adding a new gem to our `Gemfile` or even changing versions in +`Gemfile.lock` it is strongly recommended that you +[request a Security review](https://about.gitlab.com/handbook/engineering/security/#how-to-request-a-security-review). +New gems add an extra security risk for GitLab, and it is important to +evaluate this risk before we ship this to production. Technically, just adding +a new gem and pushing to a branch in our main `gitlab` project is a security +risk as it will run in CI using your GitLab.com credentials. As such you should +evaluate early on if you think this gem seems legitimate before you even +install it. + +Reviewers should also be aware of our related +[recommendations for reviewing community contributions](code_review.md#community-contributions) +and take care before running a pipeline for community contributions that +contains changes to `Gemfile` or `Gemfile.lock`. + ## License compliance Refer to [licensing guidelines](licensing.md) for ensuring license compliance. @@ -73,7 +90,7 @@ to a gem, go through these steps: apply if someone who currently works at GitLab wants to maintain the gem beyond their time working at GitLab. -When publishing a gem to RubyGems.org, also note the section on +When publishing a gem to RubyGems.org, also note the section on [gem owners](https://about.gitlab.com/handbook/developer-onboarding/#ruby-gems) in the handbook. @@ -132,7 +149,7 @@ that also relied on `thor` but had its version pinned to a vulnerable one. These changes are easy to miss in the `Gemfile.lock`. Pinning the version would result in a conflict that would need to be solved. -To avoid upgrading indirect dependencies, we can use +To avoid upgrading indirect dependencies, we can use [`bundle update --conservative`](https://bundler.io/man/bundle-update.1.html#OPTIONS). When submitting a merge request including a dependency update, |