Today we are releasing version 12.10.5 and 12.9.7 for GitLab Community Edition and Enterprise Edition.
With the release of GitLab 12.10.2 and 12.9.5 we fixed a security issue that allowed code owner validations to be bypassed if a change was pushed through the Web IDE and File Editor web interfaces. However, we were notified by customers that fixing that bug broke a legitimate workflow that was unintentionally made possible by the bug.
To accommodate customers that depended on code owners not explicitly being a
member of the project, such as being in the project's parent group or added as
a shared group to the project (see this issue
for the ongoing development), we are adding the
Disable the flag to fix the security issue and apply code owner validations for changes done through the web interface. This is the default behavior.
Note: this could break your approval workflow if it relies on code owners being in the parent group of a project without being in the project itself, even for changes that are pushed through the
Enable the flag to allow code owners to be in a parent group without being in the project explicitly. In this state however, changes pushed through the Web IDE or File Editor web interfaces will not require code owner validation.
Note: while the code owner approval requirements can be bypassed, the author of the merge request does not gain the ability to merge the request if they weren’t already a maintainer. This does not also grant the ability for the author of code changes to push their changes using the Web IDE or File Editor if they did not already have permissions to do so. You may want to review your project member permissions and protected branch settings to mitigate any security or compliance issues that may result from enabling this feature flag.
Important notes on upgrading
This version does not include any new migrations, and should not require any downtime.
Please be aware that by default the Omnibus packages will stop, run migrations,
and start again, no matter how “big” or “small” the upgrade is. This behavior
can be changed by adding a
which is only used for updates.
To update, check out our update page.
Access to GitLab Starter, Premium, and Ultimate features is granted by a paid subscription.
Alternatively, sign up for GitLab.com to use GitLab's own infrastructure.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.Share your feedback