GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — doc: de-duplicate security release processes · nodejs/node@25fb34c

File tree

Expand file treeCollapse file tree
Open diff view settings
Filter options
  • doc/guides
    • security_announcement_process.md
    • security_release_process.md
Expand file treeCollapse file tree
Open diff view settings
Collapse file

‎doc/guides/security_announcement_process.md‎

Copy file name to clipboardExpand all lines: doc/guides/security_announcement_process.md
-61Lines changed: 0 additions & 61 deletions
This file was deleted.
Collapse file

‎doc/guides/security_release_process.md‎

Copy file name to clipboard
+63-41Lines changed: 63 additions & 41 deletions
  • Display the source diff
  • Display the rich diff
Original file line numberDiff line numberDiff line change
@@ -1,61 +1,83 @@
11
# Security Release Process
22

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

69
## Planning
710

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

11-
* [ ] Get agreement on the list of vulnerabilities to be addressed.
14+
* [ ] Get agreement on the list of vulnerabilities to be addressed:
15+
* ***LINKS TO VULNS...***
1216

13-
* [ ] Get agreement on the planned date for the releases.
17+
* [ ] Get agreement on the planned date for the release: ***RELEASE DATE***
1418

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

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

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

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

28-
* [ ] Ensure the pre-announce is sent out as outlined in the
29-
[security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md).
34+
* Send pre-release announcement to
35+
https://groups.google.com/forum/#!forum/nodejs-sec.
36+
One of the existing managers can give access (Ben
37+
Noordhuis, Rod Vagg, Michael Dawson). ***LINK TO EMAIL***
38+
39+
* Post pre-release announcement in vulnerabilities section of Nodejs.org blog
40+
(https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability).
41+
Use last pre-release announcement as a template (it includes blog metadata
42+
such as updates to the banner on the Node.js website to indicate security
43+
releases are coming). Submit PR and leave 1 hour for review. After one hour
44+
even if no reviews, land anyway so that we don't have too big a gap between
45+
post to nodejs-sec and blog. Text was already reviewed in security repo so is
46+
unlikely to attract much additional comment. ***LINK TO BLOG PR AND POST***
3047

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

38-
* [ ] Send an email to the docker official image
39-
[maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS)
40-
with an FYI that security releases will be going out on the agreed date.
55+
## Release day
4156

42-
* [ ] Open an issue in the [docker-node](https://github.com/nodejs/docker-node)
43-
repo and get one or more volunteers to be available to review the PR to update
44-
Node.js versions in the docker-node repo immediately after the release.
57+
* [ ] The releaser(s) run the release process to completion.
4558

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

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

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

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

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

84-
* [ ] Ensure that the announced CVEs are reported to Mitre as per the
85-
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md).
86-
87-
* [ ] Ensure that the announced CVEs are updated in the cve-management
88-
repository as per the
89-
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md)
90-
so that they are listed under Announced.
106+
* [ ] If we allocated CVES:
107+
* [ ] Ensure that the announced CVEs are reported to Mitre as per the
108+
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md).
109+
* [ ] Ensure that the announced CVEs are updated in the cve-management
110+
repository as per the
111+
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md)
112+
so that they are listed under Announced.
91113

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

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

98-
* [ ] Ensure the issue in the private security repo for the release is closed
120+
* [ ] Ensure this issue in the private security repo for the release is closed
99121
out.

0 commit comments

Comments
0 (0)
You are visitor 01402520 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.