Announcement: Security Developer Workflow is changing
What is changing?
Starting with the next Security Release, there are two specific changes in the Security Developer Workflow: one related to Security issues and another related to Security merge requests.
What is changing with the Security issues?
Engineers won't need to edit the Security Release description to add Security issues and merge requests. Instead, in order to include a GitLab Security issue this one needs to be mark as related to the Security Release Tracking issue.
Additionally, the Links
section of the Security issue template was simplified and it's no longer required to write down the merge requests associated with the security issue.
Example of Linked issues in a Security Release Tracking issue |
Example of Links section in a GitLab Security issue
|
---|---|
![]() |
![]() |
What is changing with the Security merge requests?
Security merge requests need to mention in their description the GitLab Security issue they belong to:
### Related issues:
Related to <link_to_GitLab_Security_issue>
An example can be found on https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/300#related-issues.
As an Engineer, how does this impact me?
If you're an engineer preparing a security fix for GitLab or for Omnibus GitLab this change has a potential of impacting your workflow. Make sure you're using the latest version of the Security issue template and the Security merge request template and follow the steps there.
Note: We're currently moving Omnibus security development from dev.gitlab.org
to GitLab Security
When is the next security release?
Details for the next security release can be found here: https://gitlab.com/gitlab-org/gitlab/issues/209019. Due date is still to be agreed upon.
If you have any other question or concern, please submit it to this issue.