Merge branch 'evn-rm-sec-release' into 'master'

Clarify security release manager and add some cross-links

Closes organization#61

See merge request !5420

source/handbook/engineering/critical-release-process/index.html.md

@@ -10,7 +10,7 @@ deployments and announcements. This assumes that a critical patch will take
 roughly one week to deploy, however this will vary depending on the
 vulnerability and number of releases to be patched.
-Also see the [developer release process](https://gitlab.com/gitlab-org/release-tools/blob/master/doc/security.md)
+Also see the [security release process](https://gitlab.com/gitlab-org/release-tools/blob/master/doc/security.md)
 for more details on what needs to be done to create a security release.
 ```
@@ -20,8 +20,9 @@ for more details on what needs to be done to create a security release.
 - [ ] Create a confidential issue for diagnosing, discussing, and mitigating the vulnerability in the GitLab CE repository.
 - [ ] Create a confidential issue for the release (using the rest of this document as a rough template). Include a reference to the vulnerability issue and merge request when it exists. This issue should include information on which releases are vulnerable and which will receive a patch.
 - [ ] Branch off of the dev CE master branch for pushing patches
-- [ ] Create a Work-In-Progress merge request against dev security branch, assigned to the release manager for the current release.
-- [ ] Fix build failures (owner: release managers)
+- [ ] Designate a "security release manager" to act as the release manager for this security release. By default, the security release manager is the RM from the _previous_ release. Having one RM for the security release - even though a security release will typically span multiple prior versions - is more efficient and less likely to lead to confusion or unintended "leaking" of the vulnerability. By designating the RM from the _previous_ release, the RM for the _current_ release is not hindered in their work to get out the next release (candidate).
+- [ ] Create a Work-In-Progress merge request against dev security branch, assign to the release manager.
+- [ ] Fix build failures (owner: release manager)
 - [ ] Install mitigation for GitLab.com, GitHost.io (if possible) and any other vulnerable infrastructure hosts, create an issue in the infrastructure project describing the mitigation and impact.
 ### Day one:
@@ -33,7 +34,7 @@ for more details on what needs to be done to create a security release.
 ### Day two:
-- [ ] Cherry-pick all patches to releases -> stable branches (owner: release managers)
+- [ ] Cherry-pick all patches to releases -> stable branches (owner: release manager)
 - [ ] Validate security fixes for current release (owner: dev team)
 - [ ] Write WIP blog post against www-gitlab-com on dev.gitlab.org about security update, mitigation steps (include HAProxy/Apache/nginx workarounds): (owner: security lead)
 - [ ] Send pre-announcement e-mail to general security list and contacts (owners: customer relations / marketing)

source/handbook/engineering/index.html.md

@@ -58,7 +58,7 @@ See [the fix4all description](/handbook/engineering/fix4all/).
 The [release-tools repository](https://gitlab.com/gitlab-org/release-tools/tree/master)
 contains useful information about the responsibilities and tasks performed
-by a release manager.
+by a [release manager](https://gitlab.com/gitlab-org/release-tools/blob/master/doc/release-manager.md).
 Because of the volume of work required to get a release out the door, there
 will be two primary release managers:
@@ -67,7 +67,7 @@ will be two primary release managers:
 2. One in Europe/Middle East/Africa (EMEA) or Asia Pacific (APAC)
 Trained release managers, one in Americas and one on EMEA/APAC, will
-ultimately be in charge of making sure the RCs get created and deployed.
+ultimately be in charge of making sure the release candidates (RCs) get created and deployed.
 * These release managers need to be very vocal if they need help or something
 is blocking the release candidate (RC)

source/handbook/infrastructure/index.html.md

@@ -59,7 +59,7 @@ Staging access is treated at the same level as production access because it cont
 Any other engineer, or lead, or manager at any level will not have access to production, and, in case some information is needed from production it must be obtained by a production engineer through an issue in the infrastructure issue tracker.
-There is one temporary exception: release managers require production access to perform deploys, they will have production access until production engineering can offer a deployment automation that does not require chef nor ssh access. This is an ongoing effort.
+There is one temporary exception: [release managers](/release-managers) require production access to perform deploys, they will have production access until production engineering can offer a deployment automation that does not require chef nor ssh access. This is an ongoing effort.
 #### Production Engineering Resources

source/handbook/infrastructure/security/index.html.md

@@ -69,3 +69,7 @@ Issues with an `SL2` or `SL3` rating should also be brought to the attention of
 - Safety valve: If something is "truly urgent", pinging leads in the issues when they are created is the best
 way to go, so it can be made Next Patch Release. This will often be preceded by loud debate and concurrence on
 chat.
+
+## Security releases
+
+The processes for security releases is described with a checklist of events on the [critical release process](/handbook/engineering/critical-release-process) page, as well as in the [release-tools](https://gitlab.com/gitlab-org/release-tools/blob/master/doc/security.md) project.

source/jobs/production-engineer/index.html.md

@@ -49,8 +49,8 @@ practices like TDD or continuous integration (to start with).
 * Building the [automation to scale out](https://gitlab.com/gitlab-com/infrastructure/issues/892) and scaling out our fleet.
 * Building [chatops bundles for COG](https://gitlab.com/gitlab-cog/) to automate ourselves out of a job.
 * Helping building and maintaining core GitLab.com infrastructure pieces like [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse/)
-* Helping drive production ready large scale features.
-* Helping release managers deploying and troubleshooting new versions of GitLab-EE.
+* Helping drive production-ready large-scale features.
+* Helping [release managers](/handbook/engineering/#release-managers) deploy and troubleshoot new versions of GitLab-EE.
 * Helping the build team to ship complex pieces of infrastructure in a way that just work out of the box.
 * Whatever is on the [infrastructure issue tracker](https://gitlab.com/gitlab-com/infrastructure/issues) and you feel passionate about.

source/release-managers/index.html.haml

@@ -13,7 +13,7 @@ suppress_header: true
       GitLab Release Managers
     .release-manager-badge
     .description
-      We salute upcoming and past release managers for
+      We salute upcoming and past <a href="https://gitlab.com/gitlab-org/release-tools/blob/master/doc/release-manager.md">release managers</a> for
       <a href="https://about.gitlab.com/2015/06/25/release-manager-the-invisible-hero/">helping deliver
       GitLab every month on the 22nd.</a> The release train always arrives on time!
     .release-manager-list