Using Set Pipeline Status of a Commit API incorrectly create a new pipeline when SHA and pipeline_id did not match
Summary
When using the Set Pipeline Status of a Commit API, if I use the correct commit SHA but the wrong pipeline_id
, the API will create a new pipeline with one stage (Stage:external
), instead of failing, which is more intuitive.
The problem is that when the SHA we use in this API is the same SHA as the latest pipeline in an MR, this can bypass the "All pipeline must success" configuration. Merge Requests with this configuration only check for the latest pipeline. This API can be used to create a bogus pipeline to trick the MR into thinking that this bogus pipeline is the latest pipeline and bypass configuration.
Similar problems have been describe in this comment from a related issue.
To be honest, I don't know the fundamental rationale behind this API so there may be a reason behind this. However, this behavior is not only unexpected but can be used to bypass a setting that is intended as a security/compliance check.
Steps to reproduce
- Set up a project and enable the Require a successful pipeline for merge setting.
- Create an MR that triggers a pipeline. Set up the pipeline so this always fails.
- With the settings above, this MR should not be able to be merged
- Post API request with the same SHA as the latest pipeline in MR, but use a random number for the pipeline_id and success status. Example:
curl --request POST \
--header "PRIVATE-TOKEN: glpat-12131414151" \
--url "https://gitlab.com/api/v4/projects/12345678/statuses/690fc5f6113a4eb8b8864d6d1c9bddb?state=success&name=bogusjob&pipeline_id=12345678"
- This will create a new bogus pipeline with "success" status. This is considered the latest pipeline
- The MR can be merged now even though the latest pipeline with real test fails, successfully bypassing the Require a successful pipeline for merge setting.
Example Project
awinata-ultimate-parent/pipeline-status-of-a-commit-api-test!1
What is the current bug behavior?
Using the set the pipeline status of a commit API when SHA and pipeline_id
did not match creates a new pipeline status.
What is the expected correct behavior?
I expected this to fail since the pipeline_id and SHA did not match.
Possible fixes
- Update the logic used to figure out if the pipeline exist or not
- Update the MR check logic