@node-core/utils 4.3.0 → 5.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (13) hide show
  1. package/bin/ncu-ci.js +6 -1
  2. package/components/git/security.js +120 -5
  3. package/lib/ci/run_ci.js +12 -2
  4. package/lib/github/templates/security-pre-release.md +30 -0
  5. package/lib/pr_checker.js +1 -0
  6. package/lib/prepare_security.js +157 -172
  7. package/lib/request.js +55 -0
  8. package/lib/security-announcement.js +76 -0
  9. package/lib/security-release/security-release.js +193 -0
  10. package/lib/security_blog.js +182 -0
  11. package/lib/update_security_release.js +274 -0
  12. package/package.json +1 -1
  13. package/lib/github/templates/next-security-release.md +0 -98
package/lib/github/templates/next-security-release.md DELETED
@@ -1,98 +0,0 @@
1
- ## Planning
2
-
3
- * [X] Open an [issue](https://github.com/nodejs-private/node-private) titled
4
- `Next Security Release`, and put this checklist in the description.
5
-
6
- * [ ] Get agreement on the [list of vulnerabilities](%VULNERABILITIES_PR_URL%) to be addressed.
7
-
8
- * [ ] PR release announcements in [private](https://github.com/nodejs-private/nodejs.org-private):
9
- * [ ] pre-release: %PRE_RELEASE_PRIV%
10
- * [ ] post-release: %POS_RELEASE_PRIV%
11
- * List vulnerabilities in order of descending severity
12
- * Use the "summary" feature in HackerOne to sync post-release content
13
- and CVE requests. Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
14
- * Ask the HackerOne reporter if they would like to be credited on the
15
- security release blog page
16
-
17
- * [ ] Get agreement on the planned date for the release: %RELEASE_DATE%
18
-
19
- * [ ] Get release team volunteers for all affected lines:
20
- %AFFECTED_LINES%
21
-
22
- ## Announcement (one week in advance of the planned release)
23
-
24
- * [ ] Check that all vulnerabilities are ready for release integration:
25
- * PRs against all affected release lines or cherry-pick clean
26
- * PRs with breaking changes have a
27
- [--security-revert](#Adding-a-security-revert-option) option if possible.
28
- * Approved
29
- * (optional) Approved by the reporter
30
- * Build and send the binary to the reporter according to its architecture
31
- and ask for a review. This step is important to avoid insufficient fixes
32
- between Security Releases.
33
- * Have CVEs
34
- * Make sure that dependent libraries have CVEs for their issues. We should
35
- only create CVEs for vulnerabilities in Node.js itself. This is to avoid
36
- having duplicate CVEs for the same vulnerability.
37
- * Described in the pre/post announcements
38
-
39
- * [ ] Pre-release announcement to nodejs.org blog: TBD
40
- (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to
41
- nodejs/nodejs.org)
42
-
43
- * [ ] Pre-release announcement [email](https://groups.google.com/forum/#!forum/nodejs-sec): TBD
44
- * Subject: `Node.js security updates for all active release lines, Month Year`
45
-
46
- * [ ] CC `oss-security@lists.openwall.com` on pre-release
47
- * [ ] Forward the email you receive to `oss-security@lists.openwall.com`.
48
-
49
- * [ ] Create a new issue in [nodejs/tweet](https://github.com/nodejs/tweet/issues)
50
-
51
- * [ ] Request releaser(s) to start integrating the PRs to be released.
52
-
53
- * [ ] Notify [docker-node](https://github.com/nodejs/docker-node/issues) of upcoming security release date: TBD
54
-
55
- * [ ] Notify build-wg of upcoming security release date by opening an issue
56
- in [nodejs/build](https://github.com/nodejs/build/issues) to request WG members are available to fix any CI issues: TBD
57
-
58
- ## Release day
59
-
60
- * [ ] [Lock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#before-the-release)
61
-
62
- * [ ] The releaser(s) run the release process to completion.
63
-
64
- * [ ] [Unlock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#after-the-release)
65
-
66
- * [ ] Post-release announcement to Nodejs.org blog:
67
- * (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to
68
- nodejs/nodejs.org)
69
-
70
- * [ ] Post-release announcement in reply email: TBD
71
-
72
- * [ ] Notify `#nodejs-social` about the release.
73
-
74
- * [ ] Comment in [docker-node][] issue that release is ready for integration.
75
- The docker-node team will build and release docker image updates.
76
-
77
- * [ ] For every H1 report resolved:
78
- * Close as Resolved
79
- * Request Disclosure
80
- * Request publication of H1 CVE requests
81
- * (Check that the "Version Fixed" field in the CVE is correct, and provide
82
- links to the release blogs in the "Public Reference" section)
83
-
84
- * [ ] PR machine-readable JSON descriptions of the vulnerabilities to the
85
- [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core)
86
- vulnerability DB.
87
- * For each vulnerability add a `#.json` file, one can copy an existing
88
- [json](https://github.com/nodejs/security-wg/blob/0d82062d917cb9ddab88f910559469b2b13812bf/vuln/core/78.json)
89
- file, and increment the latest created file number and use that as the name
90
- of the new file to be added. For example, `79.json`.
91
-
92
- * [ ] Close this issue
93
-
94
- * [ ] Make sure the PRs for the vulnerabilities are closed.
95
-
96
- * [ ] PR in that you stewarded the release in
97
- [Security release stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards).
98
- If necessary add the next rotation of the steward rotation.