2018-04-12: 10.7.0rc5 (or 6) exception request for gitlab-org/gitlab-ce!18327 + gitlab-org/gitlab-ce!18173 + gitlab-org/gitlab-ee!5313
NOTE: The referenced merge requests are not merged yet. I'm hopeful they will be merged before EOD 13th April, but I wanted to get the exception request in as early as possible. The implementation is now substantially complete, and a security review is pending on the 12th April, so I expect we're on track for an exception - if approved - to go into either rc5 or rc6.
Exception request
Merge request to be considered for picking: gitlab-org/gitlab-ce!18173 + gitlab-org/gitlab-ee!5313
Why it needs to be picked
NOTE: these MRs depend on bumping gitlab-workhorse v4.0.0 to v4.1.0: gitlab-org/gitlab-workhorse#162 (closed) (gitlab-org/gitlab-ce!18327) and gitaly v0.95.0 -> v0.96.1: https://gitlab.com/gitlab-org/gitaly/blob/master/CHANGELOG.md.
The GCP Migration has a target of synchronizing all repositories by the end of April. Earlier is better, later is worse.
Several hundred repositories cannot be synced with the existing code. The linked MRs introduce a new syncing mechanism which can be used when the existing git fetch
mechanism fails - mostly these are corrupt and too-large repositories.
If we do not have this mechanism available in GitLab v10.7, the progress of the migration will be delayed, either until after %10.8 or, more likely, until we can design and run a manual synchronization process using rsync between the two repositories.
We considered and rejected the rsync approach during the planning stage as it was a one-time solution to a general problem that carried significant risks. In particular, as the bookkeeping would be manual, rather than automated, it is probable that mistakes leading to data loss (at failover) would be made.
Mistakes during the rsync process could also lead to data loss on the primary, disclosure of data, etc.
This code is predominately for the benefit of GitLab.com, so I did consider hotpatching our Azure and GCP hosts. However, the feature necessarily stretches across four separate repositories (gitlab-ee, gitaly-proto, gitaly, gitlab-workhorse), making hotpatching a daunting prospect.
Potential negative impact of picking
An undetected security flaw in the code could lead to a systematic compromise of all repositories on GitLab.com and other deployments, allowing an attacker to download every single repository on all GitLab instances. This could affect all 4 million users on GitLab.com and all our customers too.
Although the hazard is high, the risk is low. We're re-using existing security primitives throughout the implementation, and the authentication paths are well-tested. In addition, @jritchey will be performing an audit of the code and architecture from a security perspective. Obviously, any approval should be provisional upon this being satisfactory.
If this hypothetical bug does exist, it'll get deployed into %10.8 rather than %10.7, so I don't think it's a great reason to avoid picking.
Sign-off
-
Release manager: @rspeicher -
Engineering lead: @DouweM -
Engineering director: @tommy.morgan
/cc @edjdev for visibility
Note: if you are the last person to sign off, or about to close this issue, please check that gitlab-org/gitlab-ce!18327 + gitlab-org/gitlab-ce!18173 + gitlab-org/gitlab-ee!5313 have the correct milestone and label set so that the release managers will pick it.