Skip to content

FAQ: Move security development as-is to GitLab

Frequently asked questions of Move security development as-is to GitLab

As a developer, is there any difference from the original Security workflow on dev?

Yes, there's an important one. After the single codebase, all development moved to the GitLab Enterprise Edition repository. This implies that for a release based on the single codebase, you only need to submit your merge requests to the GitLab Security repository, and the Merge Train will sync your changes to gitlab-org/security/gitlab-foss.

The rest of the process remains as is, you can find it on Developer security process.

What should I do if I have opened issues and/or merge request on gitlabhq and gitlab-ee?

gitlabhq and gitlab-ee repositories are becoming a read-only mirror, so we invite you to create your security issue and corresponding merge requests on the GitLab security repository. Security issue and merge request templates were also updated, please make sure to use these ones.

To prevent developers from continuing to use the dev.gitlab.org projects, we'll do the following changes:

  • ✅ On Dec 19, 2019:
    • Issues and merge requests will be closed on those repositories.
    • Merge requests will be locked on those repositories.
  • ✅ On Dec 20th, 2019: Push to branches on those repositories will be disabled. Only @gitlab-release-tools-bot will be authorized to push.
    • Update: Given dev.gitlab.org is not using a EE license, we don't have the granularity to only authorize specific users. Instead, security branches were protected from pushing to these - &121 (comment 263733090)

When is the next security release?

Details for the next security release can be found here: https://gitlab.com/gitlab-org/gitlab/issues/37477. Due date is still to be agreed.

What about the other steps on the security release process?

On this iteration, we're only migrating the development of security fixes to GitLab.com. The rest of the security release steps (promotion of packages, creation of the blog post, etc) stays the same.

What are the changes for the other roles? (Security Engineer, QA Engineer)

None. Since we didn't change the security release process itself, the process for these roles stays the same.

What about the other components of the GitLab ecosystem?

We believe the Security group can also host the security development for Omnibus, GitLab Pages, Gitaly and GitLab Workhorse. We invite maintainers of those projects to evaluate if Security fits their needs, so we can start that migration soon.

Where I can find more information about this migration?

There are some epics and issues you can refer to:

After the migration has been completed, what are the next steps?

This is just a small, but significant step, towards moving all the security release processes to GitLab.com. The next steps completed are:

If you have any other question, please submit it to this issue.

Edited by Mayra Cabrera