Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: de-duplicate security release processes #30996

Closed
wants to merge 1 commit into from
Closed

doc: de-duplicate security release processes #30996

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 0 additions & 61 deletions doc/guides/security_announcement_process.md
View file
Open in desktop

This file was deleted.

104 changes: 63 additions & 41 deletions doc/guides/security_release_process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,61 +1,83 @@
# Security Release Process

The security release process covers the steps required to plan/implement
a security release.
The security release process covers the steps required to plan/implement a
security release. This document is copied into the description of the Next
Security Release, and used to track progess on the release. It contains
***TEXT LIKE THIS*** which will be replaced during the release process with
the information described.

## Planning

* [ ] Open an issue in the private security repo titled `Next Security Release`
and add the planning checklist to the description.
and add this planning checklist to the description.

* [ ] Get agreement on the list of vulnerabilities to be addressed.
* [ ] Get agreement on the list of vulnerabilities to be addressed:
* ***LINKS TO VULNS...***

* [ ] Get agreement on the planned date for the releases.
* [ ] Get agreement on the planned date for the release: ***RELEASE DATE***

* [ ] Once agreement on the list and date has been agreed, validate that all
vulnerabilities have been assigned a CVE following the
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md).
* [ ] Validate that all vulnerabilities have been assigned a CVE. Upstream deps
such as OpenSSL and NPM will have CVEs, issues reported on H1 may have CVEs,
otherwise allocate them by following the
[cve_management_process](https://github.com/nodejs/node/blob/master/doc/guides/cve_management_process.md).

* [ ] Co-ordinate with the Release team members to line up one or more releasers
to do the releases on the agreed date.
to do the releases on the agreed date. Releaser: ***NAME of RELEASER(S)***

* [ ] Prep for the pre-security announcement and final security announcement by
getting agreement on drafts following the
[security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md).
* [ ] Prep for the security announcements by getting agreement on drafts (use
previously announced releases as the template):
* pre-release: ***LINK TO COMMENT ON THIS ISSUE CONTAINING DRAFT***
* post-release: ***LINK TO COMMENT ON THIS ISSUE CONTAINING DRAFT***

## Announcement (one week in advance of the planned release)

* [ ] Ensure the pre-announce is sent out as outlined in the
[security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md).
* Send pre-release announcement to
https://groups.google.com/forum/#!forum/nodejs-sec.
One of the existing managers can give access (Ben
Noordhuis, Rod Vagg, Michael Dawson). ***LINK TO EMAIL***

* Post pre-release announcement in vulnerabilities section of Nodejs.org blog
(https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability).
Use last pre-release announcement as a template (it includes blog metadata
such as updates to the banner on the Node.js website to indicate security
releases are coming). Submit PR and leave 1 hour for review. After one hour
even if no reviews, land anyway so that we don't have too big a gap between
post to nodejs-sec and blog. Text was already reviewed in security repo so is
unlikely to attract much additional comment. ***LINK TO BLOG PR AND POST***

* [ ] Open an issue in the build working repository with a notification of the
date for the security release. Use this issue to co-ordinate with the build
team to ensure there will be coverage/availability of build team resources the
day of the release. Those who volunteer from the build WG should be available
in node-build during the release in case they are needed by the individual
doing the release.
in node/build during the release in case they are needed by the individual
doing the release. ***LINK TO BUILD ISSUE***

* [ ] Send an email to the docker official image
[maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tianon @yosifkit -- could you please subscribe to https://groups.google.com/forum/#!forum/nodejs-sec ? Having to send the announcement emails to two distribution lists seems unnecessary. Note that the list is SPAM free. The only posts to it are the pre and post release announcements, and the process currently requires docker-specific notifications both pre and post release.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely, I'm subscribed and I believe @yosifkit is as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So my extra email today was just spam :-(. Sorry! But it won't happen again if we get this landed.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a problem, I'd much rather get over-notified than under. 👍

with an FYI that security releases will be going out on the agreed date.
## Release day

* [ ] Open an issue in the [docker-node](https://github.com/nodejs/docker-node)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nodejs/docker could some members please subscribe to https://groups.google.com/forum/#!forum/nodejs-sec ? It is extremely low-traffic, it consists of one email a week before sec releases to warn you that they are coming, and of the date, and another email after the release so you can know to be ready to continue the docker release process.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

repo and get one or more volunteers to be available to review the PR to update
Node.js versions in the docker-node repo immediately after the release.
* [ ] The releaser(s) run the release process to completion.

* [ ] Call on the sec release volunteer(s) to start integrating the PRs, running
the CI jobs, and generally prepping the release.
* [ ] Send post-release announcement as a reply to the
original message in https://groups.google.com/forum/#!forum/nodejs-sec
***LINK TO EMAIL***

## Release day
* [ ] Update the blog post in
https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability
with the information that releases are available and the full
vulnerability details. Keep the original blog content at the
bottom of the blog. Use this as an example:
https://github.com/nodejs/nodejs.org/blob/master/locale/en/blog/vulnerability/june-2016-security-releases.md.
Make sure to update the date in the slug so that it will move to
the top of the blog list, and not that it updates the
banner on Node.js org to indicate the security release(s) are
available. ***LINK TO PR***

* [ ] Co-ordinate with the Release team members and keep up to date on progress.
Get an guesstimate of when releases may be ready and send an FYI to the docker
official image
[maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS).
*Note*: If the release blog obviously points to the people having caused the
issue (for example when explicitly mentioning reverting a commit), adding
those people as a CC on the PR for the blog post to give them a heads up
might be appropriate.

* [ ] When the releases are promoted, ensure the final announce goes out as per
the
[security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md).
* [ ] Email foundation contact to tweet out nodejs-sec announcement from
foundation twitter account. FIXME - who is this contact?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nodejs/tsc who is this contact? Is this even correct anymore? I think the twitter account may be in process of becoming a direct TSC responsibility again?


* [ ] Create a PR to update the Node.js version in the official docker images.
* Checkout the docker-node repo.
Expand All @@ -81,19 +103,19 @@ a security release.
[maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS)
indicating that the PR is open.

* [ ] Ensure that the announced CVEs are reported to Mitre as per the
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md).

* [ ] Ensure that the announced CVEs are updated in the cve-management
repository as per the
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md)
so that they are listed under Announced.
* [ ] If we allocated CVES:
* [ ] Ensure that the announced CVEs are reported to Mitre as per the
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md).
* [ ] Ensure that the announced CVEs are updated in the cve-management
repository as per the
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md)
so that they are listed under Announced.

* [ ] PR machine-readable JSON descriptions of the vulnerabilities to the
[core](https://github.com/nodejs/security-wg/tree/master/vuln/core)
vulnerability DB.
vulnerability DB. ***LINK TO PR***

* [ ] Make sure the PRs for the vulnerabilities are closed.

* [ ] Ensure the issue in the private security repo for the release is closed
* [ ] Ensure this issue in the private security repo for the release is closed
out.