From 9d4ff736d74d8b0e3647c8014c4446bc139f481d Mon Sep 17 00:00:00 2001
From: RafaelGSS <rafael.nunu@hotmail.com>
Date: Tue, 16 Jul 2024 18:16:54 -0300
Subject: [PATCH 1/4] doc: update security-release process to automated one
---
doc/contributing/security-release-process.md | 291 +++++++------------
1 file changed, 107 insertions(+), 184 deletions(-)
diff --git a/doc/contributing/security-release-process.md b/doc/contributing/security-release-process.md
index aca702e7615c49..6070b87357e130 100644
--- a/doc/contributing/security-release-process.md
+++ b/doc/contributing/security-release-process.md
@@ -43,191 +43,118 @@ The current security stewards are documented in the main Node.js
## Planning
-* [ ] Open an [issue](https://github.com/nodejs-private/node-private) titled
- `Next Security Release`, and put this checklist in the description.
-
-* [ ] Get agreement on the list of vulnerabilities to be addressed:
- * _**H1 REPORT LINK**_: _**DESCRIPTION**_ (_**CVE or H1 CVE request link**_)
- * v10.x, v12.x: _**LINK to PR URL**_
- * ...
-
-* [ ] PR release announcements in [private](https://github.com/nodejs-private/nodejs.org-private):
- * (Use previous PRs as templates. Don't forget to update the site banner and
- the date in the slug so that it will move to the top of the blog list.)
- * (Consider using a [Vulnerability Score System](https://www.first.org/cvss/calculator/3.1)
- to identify severity of each report)
- * Share the patch with the reporter when applicable.
- It will increase the fix accuracy.
- * [ ] pre-release: _**LINK TO PR**_
- * [ ] post-release: _**LINK TO PR**_
- * List vulnerabilities in order of descending severity
- * Use the "summary" feature in HackerOne to sync post-release content
- and CVE requests. Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
- * Ask the HackerOne reporter if they would like to be credited on the
- security release blog page:
- ```text
- Thank you to <name> for reporting this vulnerability.
- ```
-
-* [ ] Get agreement on the planned date for the release: _**RELEASE DATE**_
-
-* [ ] Get release team volunteers for all affected lines:
- * v12.x: _**NAME of RELEASER(S)**_
- * ... other lines, if multiple releasers
+1. **Generating Next Security Release PR**
+ * Run `git node security --start` inside [security-release][] repository.
+ * This command generates a new `vulnerabilities.json` file with HackerOne
+ reports chosen to be released in the `security-release/next-security-release`
+ folder.
+ * It also creates the Pull Request used to manage the security release.
+
+2. **Review of Reports:**
+ * Reports can be added or removed using the following commands:
+ * Use the "summary" feature in HackerOne. Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
+ * `git node security --add-report=report_id`
+ * `git node security --remove-report=report_id`
+
+3. **Assigning Severity and Writing Team Summary:**
+ * Assign a severity and write a team summary on HackerOne for the reports
+ chosen in the `vulnerabilities.json`.
+ * Run `git node security --sync` to update severity and summary in
+ `vulnerabilities.json`.
+
+4. **Requesting CVEs:**
+ * Request CVEs for the reports with `git node security --request-cve`.
+ * Make sure to have a green CI before running it.
+
+5. **Choosing or Updating Release Date:**
+ * Use `git node security --update-date=YYYY/MM/DD` to choose or update the
+ release date.
+ * This allows flexibility in postponing the release if needed.
+
+6. **Get release volunteers:**
+ * Get volunteers for the upcoming security release on the affected release
+ lines.
+
+7. **Preparing Pre and Post Release Blog Post:**
+ * Create a pre-release blog post using `git node security --pre-release`.
+ * Create a post-release blog post using `git node security --post-release`.
## Announcement (one week in advance of the planned release)
-* [ ] Check that all vulnerabilities are ready for release integration:
- * PRs against all affected release lines or cherry-pick clean
- * PRs with breaking changes have a
- [--security-revert](#Adding-a-security-revert-option) option if possible.
- * Approved
- * (optional) Approved by the reporter
- * Build and send the binary to the reporter according to its architecture
- and ask for a review. This step is important to avoid insufficient fixes
- between Security Releases.
- * Pass `make test`
- * Have CVEs
- * Use the "summary" feature in HackerOne to create a description for the
- CVE and the post release announcement.
- Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
- * Make sure that dependent libraries have CVEs for their issues. We should
- only create CVEs for vulnerabilities in Node.js itself. This is to avoid
- having duplicate CVEs for the same vulnerability.
- * Described in the pre/post announcements
-
-* [ ] Pre-release announcement to nodejs.org blog: _**LINK TO BLOG**_
- (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to
- nodejs/nodejs.org)
-
- If the security release will only contain an OpenSSL update consider
- adding the following to the pre-release announcement:
-
- ```text
- Since this security release will only include updates for OpenSSL, if you're using
- a Node.js version which is part of a distribution which uses a system
- installed OpenSSL, this Node.js security update might not concern you. You may
- instead need to update your system OpenSSL libraries, please check the
- security announcements for the distribution.
- ```
-
-* [ ] Pre-release announcement [email][]: _**LINK TO EMAIL**_
- * Subject: `Node.js security updates for all active release lines, Month Year`
- * Body:
- ```text
- The Node.js project will release new versions of all supported release lines on or shortly after Day of week, Month Day of Month, Year
- For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
- ```
- (Get access from existing manager: Matteo Collina, Rodd Vagg, Michael Dawson,
- Bryan English)
-
-* [ ] CC `oss-security@lists.openwall.com` on pre-release
-
-The google groups UI does not support adding a CC, until we figure
-out a better way, forward the email you receive to
-`oss-security@lists.openwall.com` as a CC.
-
-* [ ] Post in the [nodejs-social channel][]
- in the OpenJS slack asking for amplification of the blog post.
-
- ```text
- Security release pre-alert:
-
- We will release new versions of <add versions> release lines on or shortly
- after Day Month Date, Year in order to address:
-
- - # high severity issues
- - # moderate severity issues
-
- https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
- ```
-
- We specifically ask that collaborators other than the releasers and security
- steward working on the security release do not tweet or publicise the release
- until the tweet from the Node.js twitter handle goes out. We have often
- seen tweets sent out before the release and associated announcements are
- complete which may confuse those waiting for the release and also takes
- away from the work the releasers have put into shipping the releases.
-
-* [ ] Request releaser(s) to start integrating the PRs to be released.
-
-* [ ] Notify [docker-node][] of upcoming security release date: _**LINK**_
- ```text
- Heads up of Node.js security releases Day Month Year
-
- As per the Node.js security release process this is the FYI that there is going to be a security release Day Month Year
- ```
-
-* [ ] Notify build-wg of upcoming security release date by opening an issue
- in [nodejs/build][] to request WG members are available to fix any CI issues.
- ```text
- Heads up of Node.js security releases Day Month Year
-
- As per security release process this is a heads up that there will be security releases Day Month Year and we'll need people from build to lock/unlock ci and to support and build issues we see.
- ```
+1. **Publish Pre-Release Blog Post:**
+ * Publish the pre-release blog post on the `nodejs/nodejs.org` repository.
+
+2. **Send Pre-Release Accouncement:**
+ * Notify the community about the upcoming security release:
+ * `git node security --notify-pre-release`
+ * (Not supported yet)[Google Groups](https://groups.google.com/g/nodejs-sec)
+ * Email: notify <oss-security@lists.openwall.com>
+ * (Not supported yet)[Twitter](https://twitter.com/nodejs)
+ * [docker-node](https://github.com/nodejs/docker-node/issues)
+ * [build-wg](https://github.com/nodejs/build/issues)
+ We specifically ask that collaborators other than the releasers and security
+ steward working on the security release do not tweet or publicise the release
+ until the tweet from the Node.js twitter handle goes out. We have often
+ seen tweets sent out before the release and associated announcements are
+ complete which may confuse those waiting for the release and also takes
+ away from the work the releasers have put into shipping the releases.
+
+If the security release will only contain an OpenSSL update consider
+adding the following to the pre-release announcement:
+
+```text
+Since this security release will only include updates for OpenSSL, if you're using
+a Node.js version which is part of a distribution which uses a system
+installed OpenSSL, this Node.js security update might not concern you. You may
+instead need to update your system OpenSSL libraries, please check the
+security announcements for the distribution.
+```
## Release day
-* [ ] [Lock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#before-the-release)
-
-* [ ] The releaser(s) run the release process to completion.
-
-* [ ] [Unlock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#after-the-release)
-
-* [ ] Post-release announcement to Nodejs.org blog: _**LINK TO BLOG POST**_
- * (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to
- nodejs/nodejs.org)
-
-* [ ] Post-release announcement in reply [email][]: _**LINK TO EMAIL**_
- * CC: `oss-security@lists.openwall.com`
- * Subject: `Node.js security updates for all active release lines, Month Year`
- * Body:
- ```text
- The Node.js project has now released new versions of all supported release lines.
- For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
- ```
-
-* [ ] Post in the [nodejs-social channel][]
- in the OpenJS slack asking for amplification of the blog post.
- ```text
- Security release:
-
- New security releases are now available for versions <add versions> of Node.js.
-
- https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
- ```
-
-* [ ] Comment in [docker-node][] issue that release is ready for integration.
- The docker-node team will build and release docker image updates.
-
-* [ ] For every H1 report resolved:
- * Close as Resolved
- * Request Disclosure
- * Request publication of [H1 CVE requests][]
- * (Check that the "Version Fixed" field in the CVE is correct, and provide
- links to the release blogs in the "Public Reference" section)
- * In case the reporter doesn't accept the disclosure follow this process:
- * Remove the original report reference within the reference text box and
- insert the public URL you would like to be attached to this CVE.
- * Then uncheck the Public Disclosure on HackerOne box at the bottom of the
- page.
- 
-
-* [ ] PR machine-readable JSON descriptions of the vulnerabilities to the
- [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core)
- vulnerability DB. _**LINK TO PR**_
- * For each vulnerability add a `#.json` file, one can copy an existing
- [json](https://github.com/nodejs/security-wg/blob/0d82062d917cb9ddab88f910559469b2b13812bf/vuln/core/78.json)
- file, and increment the latest created file number and use that as the name
- of the new file to be added. For example, `79.json`.
-
-* [ ] Close this issue
-
-* [ ] Make sure the PRs for the vulnerabilities are closed.
-
-* [ ] PR in that you stewarded the release in
- [Security release stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards).
- If necessary add the next rotation of the steward rotation.
+1. **Lock down the CI:**
+ * Lock down the CI to prevent public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
+
+2. **Release:**
+ * Make sure the CI on all release proposals is green (test-V8, CITGM, etc).
+ * Follow the release process documented [here](https://github.com/nodejs/node/blob/main/doc/contributing/releases.md)
+
+3. **Unlock the CI:**
+ * Unlock the CI to allow public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
+
+4. **Publish Post-Release Blog Post:**
+ * Publish the post-release blog post on the `nodejs/nodejs.org` repository.
+
+5. **Notify the community:**
+ * Notify the community about the upcoming security release:
+ * Slack: `#nodejs-social`
+ * [docker-node](https://github.com/nodejs/docker-node/issues)
+ * [build-wg](https://github.com/nodejs/build/issues)
+ * Email: notify <oss-security@lists.openwall.com>
+
+## Post-Release
+
+1. **Merge the Next Security Release PR:**
+ * This involves moving the `vulnerabilities.json` file from
+ `security-release/next-security-release` to the `security-release/YYYY-MM-DD`
+ folder and merging the PR.
+
+2. **Cleanup:**
+ * Close PRs and backports.
+ * Close any pending PRs related to the security release.
+ * Close HackerOne reports:
+ * Close Resolved
+ * Request Disclosure
+ * Request publication of H1 CVE requests
+ * In case the reporter doesn't accept the disclosure follow this process:
+ Remove the original report reference within the reference text box and
+ insert the public URL you would like to be attached to this CVE.
+ Then uncheck the Public Disclosure on HackerOne box at the bottom of the
+ page.
+ 
+ * PR machine-readable JSON descriptions of the vulnerabilities to the [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core)
+ vulnerability DB.
+ * Add yourself as a steward in the [Security Release Stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards)
## Adding a security revert option
@@ -298,8 +225,4 @@ The steps to correct CVE information are:
* Include all the details that need updating within the form
* Submit the request
-[H1 CVE requests]: https://hackerone.com/nodejs/cve_requests
-[docker-node]: https://github.com/nodejs/docker-node/issues
-[email]: https://groups.google.com/forum/#!forum/nodejs-sec
-[nodejs-social channel]: https://openjs-foundation.slack.com/archives/C0142A39BNE
-[nodejs/build]: https://github.com/nodejs/build/issues
+[security-release]: https://github.com/nodejs-private/security-release
From dc1e049b897a985a8d6dbc0611337a2ab0dab90e Mon Sep 17 00:00:00 2001
From: Rafael Gonzaga <rafael.nunu@hotmail.com>
Date: Tue, 16 Jul 2024 19:11:49 -0300
Subject: [PATCH 2/4] fixup! Apply suggestions from code review
Co-authored-by: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com>
---
doc/contributing/security-release-process.md | 36 ++++++++++----------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/doc/contributing/security-release-process.md b/doc/contributing/security-release-process.md
index 6070b87357e130..d4400c3d99bdee 100644
--- a/doc/contributing/security-release-process.md
+++ b/doc/contributing/security-release-process.md
@@ -48,11 +48,11 @@ The current security stewards are documented in the main Node.js
* This command generates a new `vulnerabilities.json` file with HackerOne
reports chosen to be released in the `security-release/next-security-release`
folder.
- * It also creates the Pull Request used to manage the security release.
+ * It also creates the pull request used to manage the security release.
2. **Review of Reports:**
* Reports can be added or removed using the following commands:
- * Use the "summary" feature in HackerOne. Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
+ * Use the "summary" feature in HackerOne. Example [2038134](https://hackerone.com/reports/2038134)
* `git node security --add-report=report_id`
* `git node security --remove-report=report_id`
@@ -64,7 +64,7 @@ The current security stewards are documented in the main Node.js
4. **Requesting CVEs:**
* Request CVEs for the reports with `git node security --request-cve`.
- * Make sure to have a green CI before running it.
+ * Make sure to have a green CI before requesting a CVE.
5. **Choosing or Updating Release Date:**
* Use `git node security --update-date=YYYY/MM/DD` to choose or update the
@@ -75,7 +75,7 @@ The current security stewards are documented in the main Node.js
* Get volunteers for the upcoming security release on the affected release
lines.
-7. **Preparing Pre and Post Release Blog Post:**
+7. **Preparing Pre and Post Release Blog Posts:**
* Create a pre-release blog post using `git node security --pre-release`.
* Create a post-release blog post using `git node security --post-release`.
@@ -87,27 +87,27 @@ The current security stewards are documented in the main Node.js
2. **Send Pre-Release Accouncement:**
* Notify the community about the upcoming security release:
* `git node security --notify-pre-release`
- * (Not supported yet)[Google Groups](https://groups.google.com/g/nodejs-sec)
+ * (Not yet supported) [Google Groups](https://groups.google.com/g/nodejs-sec)
* Email: notify <oss-security@lists.openwall.com>
- * (Not supported yet)[Twitter](https://twitter.com/nodejs)
+ * (Not yet supported) [Twitter / X](https://x.com/nodejs)
* [docker-node](https://github.com/nodejs/docker-node/issues)
* [build-wg](https://github.com/nodejs/build/issues)
We specifically ask that collaborators other than the releasers and security
- steward working on the security release do not tweet or publicise the release
- until the tweet from the Node.js twitter handle goes out. We have often
- seen tweets sent out before the release and associated announcements are
- complete which may confuse those waiting for the release and also takes
- away from the work the releasers have put into shipping the releases.
+ steward working on the security release do not tweet or publicize the release
+ until the tweet from Node.js goes out. We have often
+ seen tweets sent out before the release is
+ complete, which may confuse those waiting for the release and take
+ away from the work the releasers have put into shipping the release.
-If the security release will only contain an OpenSSL update consider
+If the security release will only contain an OpenSSL update, consider
adding the following to the pre-release announcement:
```text
Since this security release will only include updates for OpenSSL, if you're using
-a Node.js version which is part of a distribution which uses a system
-installed OpenSSL, this Node.js security update might not concern you. You may
-instead need to update your system OpenSSL libraries, please check the
-security announcements for the distribution.
+a Node.js version which is part of a distribution that uses a system
+installed OpenSSL, this Node.js security update may not concern you, instead,
+you may need to update your system OpenSSL libraries. Please check the
+security announcements for more information.
```
## Release day
@@ -116,8 +116,8 @@ security announcements for the distribution.
* Lock down the CI to prevent public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
2. **Release:**
- * Make sure the CI on all release proposals is green (test-V8, CITGM, etc).
- * Follow the release process documented [here](https://github.com/nodejs/node/blob/main/doc/contributing/releases.md)
+ * Verify the CI is green on all release proposals (test-V8, CITGM, etc).
+ * Follow the [release process](https://github.com/nodejs/node/blob/main/doc/contributing/releases.md).
3. **Unlock the CI:**
* Unlock the CI to allow public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
From 5f847578881f7058770ce539f0fa9cd463fa2fce Mon Sep 17 00:00:00 2001
From: RafaelGSS <rafael.nunu@hotmail.com>
Date: Wed, 24 Jul 2024 11:26:10 -0300
Subject: [PATCH 3/4] fixup! apply cr suggestions
---
doc/contributing/security-release-process.md | 194 ++++++++++---------
1 file changed, 106 insertions(+), 88 deletions(-)
diff --git a/doc/contributing/security-release-process.md b/doc/contributing/security-release-process.md
index d4400c3d99bdee..7a016643481821 100644
--- a/doc/contributing/security-release-process.md
+++ b/doc/contributing/security-release-process.md
@@ -43,61 +43,79 @@ The current security stewards are documented in the main Node.js
## Planning
-1. **Generating Next Security Release PR**
- * Run `git node security --start` inside [security-release][] repository.
- * This command generates a new `vulnerabilities.json` file with HackerOne
- reports chosen to be released in the `security-release/next-security-release`
- folder.
- * It also creates the pull request used to manage the security release.
-
-2. **Review of Reports:**
- * Reports can be added or removed using the following commands:
- * Use the "summary" feature in HackerOne. Example [2038134](https://hackerone.com/reports/2038134)
- * `git node security --add-report=report_id`
- * `git node security --remove-report=report_id`
-
-3. **Assigning Severity and Writing Team Summary:**
- * Assign a severity and write a team summary on HackerOne for the reports
- chosen in the `vulnerabilities.json`.
- * Run `git node security --sync` to update severity and summary in
- `vulnerabilities.json`.
-
-4. **Requesting CVEs:**
- * Request CVEs for the reports with `git node security --request-cve`.
- * Make sure to have a green CI before requesting a CVE.
-
-5. **Choosing or Updating Release Date:**
- * Use `git node security --update-date=YYYY/MM/DD` to choose or update the
- release date.
- * This allows flexibility in postponing the release if needed.
-
-6. **Get release volunteers:**
- * Get volunteers for the upcoming security release on the affected release
- lines.
-
-7. **Preparing Pre and Post Release Blog Posts:**
- * Create a pre-release blog post using `git node security --pre-release`.
- * Create a post-release blog post using `git node security --post-release`.
+* [ ] 1\. **Generating Next Security Release PR**
+ * Run `git node security --start` inside [security-release][] repository.
+ * This command generates a new `vulnerabilities.json` file with HackerOne
+ reports chosen to be released in the `security-release/next-security-release`
+ folder.
+ * It also creates the pull request used to manage the security release.
+
+* [ ] 2\. **Review of Reports:**
+ * Reports can be added or removed using the following commands:
+ * Use the "summary" feature in HackerOne. Example [2038134](https://hackerone.com/reports/2038134)
+ * `git node security --add-report=report_id`
+ * `git node security --remove-report=report_id`
+
+* [ ] 3\. **Assigning Severity and Writing Team Summary:**
+ * [ ] Assign a severity and write a team summary on HackerOne for the reports
+ chosen in the `vulnerabilities.json`.
+ * Run `git node security --sync` to update severity and summary in
+ `vulnerabilities.json`.
+
+* [ ] 4\. **Requesting CVEs:**
+ * Request CVEs for the reports with `git node security --request-cve`.
+ * Make sure to have a green CI before requesting a CVE.
+
+* [ ] 5\. **Choosing or Updating Release Date:**
+ * Get agreement on the planned date for the release.
+ * [ ] Use `git node security --update-date=YYYY/MM/DD` to choose or update the
+ release date.
+ * This allows flexibility in postponing the release if needed.
+
+* [ ] 6\. **Get release volunteers:**
+ * Get volunteers for the upcoming security release on the affected release
+ lines.
+
+* [ ] 7\. **Preparing Pre and Post Release Blog Posts:**
+ * [ ] Create a pre-release blog post using `git node security --pre-release`.
+ * [ ] Create a post-release blog post using `git node security --post-release`.
## Announcement (one week in advance of the planned release)
-1. **Publish Pre-Release Blog Post:**
- * Publish the pre-release blog post on the `nodejs/nodejs.org` repository.
-
-2. **Send Pre-Release Accouncement:**
- * Notify the community about the upcoming security release:
- * `git node security --notify-pre-release`
- * (Not yet supported) [Google Groups](https://groups.google.com/g/nodejs-sec)
- * Email: notify <oss-security@lists.openwall.com>
- * (Not yet supported) [Twitter / X](https://x.com/nodejs)
- * [docker-node](https://github.com/nodejs/docker-node/issues)
- * [build-wg](https://github.com/nodejs/build/issues)
- We specifically ask that collaborators other than the releasers and security
- steward working on the security release do not tweet or publicize the release
- until the tweet from Node.js goes out. We have often
- seen tweets sent out before the release is
- complete, which may confuse those waiting for the release and take
- away from the work the releasers have put into shipping the release.
+* [ ] 1\. **Publish Pre-Release Blog Post:**
+ * Publish the pre-release blog post on the `nodejs/nodejs.org` repository.
+
+* [ ] 2\. **Send Pre-Release Announcement:**
+ * Notify the community about the upcoming security release:
+
+ * [ ] `git node security --notify-pre-release`
+ Except for those noted in the list below, this will create automatically the
+ issues and emails needed for the notifications.
+ * [docker-node](https://github.com/nodejs/docker-node/issues)
+ * [build-wg](https://github.com/nodejs/build/issues)
+ * [ ] (Not yet automatic - do this manually) [Google Groups](https://groups.google.com/g/nodejs-sec)
+ * Email: notify <oss-security@lists.openwall.com>
+ * [ ] (Not yet automatic - do this manually) Post in the \[nodejs-social channel]\[]
+ in the OpenJS slack asking for amplification of the blog post.
+
+ ```text
+ Security release pre-alert:
+
+ We will release new versions of <add versions> release lines on or shortly
+ after Day Month Date, Year in order to address:
+
+ * # high severity issues
+ * # moderate severity issues
+
+ https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
+ ```
+
+ We specifically ask that collaborators other than the releasers and security
+ steward working on the security release do not tweet or publicize the release
+ until the tweet from Node.js goes out. We have often
+ seen tweets sent out before the release is
+ complete, which may confuse those waiting for the release and take
+ away from the work the releasers have put into shipping the release.
If the security release will only contain an OpenSSL update, consider
adding the following to the pre-release announcement:
@@ -112,49 +130,49 @@ security announcements for more information.
## Release day
-1. **Lock down the CI:**
- * Lock down the CI to prevent public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
+* [ ] 1\. **Lock down the CI:**
+ * Lock down the CI to prevent public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
-2. **Release:**
- * Verify the CI is green on all release proposals (test-V8, CITGM, etc).
- * Follow the [release process](https://github.com/nodejs/node/blob/main/doc/contributing/releases.md).
+* [ ] 2\. **Release:**
+ * Verify the CI is green on all release proposals (test-V8, CITGM, etc).
+ * Follow the [release process](https://github.com/nodejs/node/blob/main/doc/contributing/releases.md).
-3. **Unlock the CI:**
- * Unlock the CI to allow public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
+* [ ] 3\. **Unlock the CI:**
+ * Unlock the CI to allow public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
-4. **Publish Post-Release Blog Post:**
- * Publish the post-release blog post on the `nodejs/nodejs.org` repository.
+* [ ] 4\. **Publish Post-Release Blog Post:**
+ * Publish the post-release blog post on the `nodejs/nodejs.org` repository.
-5. **Notify the community:**
- * Notify the community about the upcoming security release:
- * Slack: `#nodejs-social`
- * [docker-node](https://github.com/nodejs/docker-node/issues)
- * [build-wg](https://github.com/nodejs/build/issues)
- * Email: notify <oss-security@lists.openwall.com>
+* [ ] 5\. **Notify the community:**
+ * Notify the community that the security release has gone out:
+ * [ ] Slack: `#nodejs-social`
+ * [ ] [docker-node](https://github.com/nodejs/docker-node/issues)
+ * [ ] [build-wg](https://github.com/nodejs/build/issues)
+ * [ ] Email: notify [Google Groups](https://groups.google.com/g/nodejs-sec)
+ * Forward to <oss-security@lists.openwall.com>
## Post-Release
-1. **Merge the Next Security Release PR:**
- * This involves moving the `vulnerabilities.json` file from
- `security-release/next-security-release` to the `security-release/YYYY-MM-DD`
- folder and merging the PR.
-
-2. **Cleanup:**
- * Close PRs and backports.
- * Close any pending PRs related to the security release.
- * Close HackerOne reports:
- * Close Resolved
- * Request Disclosure
- * Request publication of H1 CVE requests
- * In case the reporter doesn't accept the disclosure follow this process:
- Remove the original report reference within the reference text box and
- insert the public URL you would like to be attached to this CVE.
- Then uncheck the Public Disclosure on HackerOne box at the bottom of the
- page.
- 
- * PR machine-readable JSON descriptions of the vulnerabilities to the [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core)
- vulnerability DB.
- * Add yourself as a steward in the [Security Release Stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards)
+* [ ] 1\. **Merge the Next Security Release PR:**
+ * This involves moving the `vulnerabilities.json` file from
+ `security-release/next-security-release` to the `security-release/YYYY-MM-DD`
+ folder and merging the PR.
+
+* [ ] 2\. **Cleanup:**
+ * [ ] Close PRs and backports.
+ * [ ] Close HackerOne reports:
+ * Close Resolved
+ * Request Disclosure
+ * Request publication of H1 CVE requests
+ * In case the reporter doesn't accept the disclosure follow this process:
+ Remove the original report reference within the reference text box and
+ insert the public URL you would like to be attached to this CVE.
+ Then uncheck the Public Disclosure on HackerOne box at the bottom of the
+ page.
+ 
+ * [ ] PR machine-readable JSON descriptions of the vulnerabilities to the [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core)
+ vulnerability DB.
+ * [ ] Add yourself as a steward in the [Security Release Stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards)
## Adding a security revert option
From d082ea9c6699b401ff2168b29651b5a736d99237 Mon Sep 17 00:00:00 2001
From: Rafael Gonzaga <rafael.nunu@hotmail.com>
Date: Fri, 26 Jul 2024 11:34:54 -0300
Subject: [PATCH 4/4] Update doc/contributing/security-release-process.md
---
doc/contributing/security-release-process.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/contributing/security-release-process.md b/doc/contributing/security-release-process.md
index 7a016643481821..62c788f1746556 100644
--- a/doc/contributing/security-release-process.md
+++ b/doc/contributing/security-release-process.md
@@ -95,7 +95,7 @@ The current security stewards are documented in the main Node.js
* [build-wg](https://github.com/nodejs/build/issues)
* [ ] (Not yet automatic - do this manually) [Google Groups](https://groups.google.com/g/nodejs-sec)
* Email: notify <oss-security@lists.openwall.com>
- * [ ] (Not yet automatic - do this manually) Post in the \[nodejs-social channel]\[]
+ * [ ] (Not yet automatic - do this manually) Post in the nodejs-social channel
in the OpenJS slack asking for amplification of the blog post.
```text