Security policy approvals bypassed after MR retargeting via dependency chain

Summary

A merge request which should be covered by the security policy was able to merge without fulfilling it, potentially due to a merge request chain not refreshing the policy after the merge request before it was merged.

Situation

Two merge requests (MR).

MR1 : branch-1 targeting main

MR2: branch-2 targeting branch-1 (Set to depend on MR1 being merged first)

A security policy project is in place covering all merge requests within the project to protected branches (main). It is strictly enforced and requests 2 approvers.

There are no restrictions on merges or merge requests between unprotected branches. So if MR2 was not set to depend on MR1 being merged, that MR would be possible to merge.

When MR1 was merged into main, MR2 was re-targeted to main and the dependency of MR1 being merged was fulfilled. The approval rules defined by the security policy was however not updated thus not enforcing approvals and the MR was merged without approvals.

We noticed that the MR reported being able to merge without approvals. We tried refreshing the page to get it to notice that the policy had changed however it did not. We thought it would block the merge when the merge button was clicked and refresh its policy. However, it did not. It merged it without approvals.

Steps to reproduce

We have not been able to reproduce it. We have used the chaining of MR's before and not seen the problem, and we have also not been able to reproduce it. It seems like we hit some kind of edge case that is difficult to pinpoint or it could be sporadic.

What is the current bug behavior?

The MR which should be covered by the project's security policy project should prevent merge without the required number of approvals however after retargeting to main, it allowed merging without approvals.

What is the expected correct behavior?

When the MR is retargeted to it should update its merge requirements (in this case 2 approvers) to match those of the branch it is being merged into.

Relevant logs and/or screenshots

The MR was merged to main without approvals. It doesn't even write that it was retargeted.

(We are pretty sure it was retargeted to main but even if it wasn't it, should still have been covered by the security policy and thus require approvals. Being covered by the policy would have just been from the time of creating the MR and not from retargeting.)

How it looks in other MRs. When the dependent MR was merged the MR was retargeted to main and where it would require approvals and after being approved it can be merged.

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of: \\\`sudo gitlab-rake gitlab:env:info\\\`)  (For installations from source run and paste the output of: \\\`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\\\`)   

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: \`sudo gitlab-rake gitlab:check SANITIZE=true\`)  (For installations from source run and paste the output of: \`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true\`)  (we will only investigate if the tests are passing)  

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.