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: add security release specifics to releases.md · nodejs/node@8b8c55d

File tree

Expand file treeCollapse file tree
Open diff view settings
Filter options
  • doc/contributing
    • releases.md
Expand file treeCollapse file tree
Open diff view settings
Collapse file

‎doc/contributing/releases.md‎

Copy file name to clipboardExpand all lines: doc/contributing/releases.md
+152Lines changed: 152 additions & 0 deletions
  • Display the source diff
  • Display the rich diff
Original file line numberDiff line numberDiff line change
@@ -119,6 +119,8 @@ Notes:
119119
* Version strings are listed below as _"vx.y.z"_ or _"x.y.z"_. Substitute for
120120
the release version.
121121
* Examples will use the fictional release version `1.2.3`.
122+
* When preparing a security release, follow the security steps in the details
123+
sections.
122124

123125
### 0. Pre-release steps
124126

@@ -216,6 +218,42 @@ Then, push to the staging branch to keep it up-to-date.
216218
$ git push upstream v1.x-staging
217219
```
218220

221+
<details>
222+
<summary>Security release</summary>
223+
224+
Security releases with private patches need to be prepared in the `nodejs-private`
225+
GitHub organisation.
226+
227+
Add the `nodejs-private` remote:
228+
229+
```console
230+
$ git remote add private [email protected]:nodejs-private/node-private.git
231+
```
232+
233+
For security releases, we generally try to only include the security patches.
234+
As there may already be commits on the `vN.x-staging` branch, it is preferable
235+
to checkout the `vN.x` branch and build up the release directly in a proposal
236+
branch.
237+
238+
```console
239+
$ git checkout vN.x
240+
$ git reset --hard upstream/vN.x
241+
```
242+
243+
The list of patches to include should be listed in the "Next Security Release"
244+
issue in `nodejs-private`. Ask the security release steward if you're unsure.
245+
246+
The `git node land` tool does not work with the `nodejs-private`
247+
organisation. To land a PR in Node.js private, use `git cherry-pick` to apply
248+
each commit from the PR. You will also need to manually apply the PR
249+
metadata (`PR-URL`, `Reviewed-by`, etc.) by amending the commit messages. If
250+
known, additionally include `CVE-ID: CVE-XXXX-XXXXX` in the commit metadata.
251+
252+
**Note**: Do not run CI on the PRs in `nodejs-private` until CI is locked down.
253+
You can integrate the PRs into the proposal without running full CI.
254+
255+
</details>
256+
219257
### 2. Create a new branch for the release
220258

221259
Create a new branch named `vx.y.z-proposal`, off the corresponding staging
@@ -305,6 +343,43 @@ $ branch-diff upstream/v1.x v1.2.3-proposal --require-label=notable-change --pla
305343
Be sure that the `<a>` tag, as well as the two headings, are not indented at
306344
all.
307345

346+
<details>
347+
<summary>Security release</summary>
348+
349+
For security releases, it is necessary to include more detailed information
350+
including which vulnerabilities have been fixed, and any revert flags or
351+
workarounds to revert to the old behaviour.
352+
353+
You can use the following template as a guide:
354+
355+
```markdown
356+
<a id="x.y.x"></a>
357+
## YYYY-MM-DD, Version x.y.z (Release Type), @releaser
358+
359+
This is a security release.
360+
361+
### Notable changes
362+
363+
* <CVE Title> (High|Medium|Low)(CVE-XXXX-XXXXX)
364+
* ...
365+
366+
### Commits
367+
368+
* Include the full list of commits since the last release here. Do not include "Working on X.Y.Z+1" commits.
369+
```
370+
371+
Alternatively, refer to one of the [previous security release changelog entries](https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V17.md#2022-01-10-version-1731-current-bethgriggs)
372+
to get an idea of the structure and level of detail.
373+
374+
For each fix, use your judgement as to whether a subheading is necessary to
375+
describe the fix in more detail. Much of this information should be able to be
376+
lifted from the "post-release" announcement (should be available in
377+
`nodejs-private`). If the CVE is being fixed in multiple release lines, try to
378+
coordinate the changelog content between the other release so the descriptions
379+
are consistent.
380+
381+
</details>
382+
308383
At the top of the root `CHANGELOG.md` file, there is a table indexing all
309384
releases in each major release line. A link to the new release needs to be added
310385
to it. Follow the existing examples and be sure to add the release to the _top_
@@ -363,6 +438,9 @@ Notable changes:
363438
PR-URL: TBD
364439
```
365440

441+
<details>
442+
<summary>Security release</summary>
443+
366444
For security releases, begin the commit message with the phrase
367445
`This is a security release.` to allow the
368446
[distribution indexer](https://github.com/nodejs/nodejs-dist-indexer) to
@@ -380,6 +458,8 @@ Notable changes:
380458
PR-URL: TBD
381459
```
382460

461+
</details>
462+
383463
### 6. Propose release on GitHub
384464

385465
Push the release branch to `nodejs/node`, not to your own fork. This allows
@@ -410,6 +490,14 @@ good place to @-mention the relevant contributors.
410490
After opening the PR, update the release commit to include `PR-URL` metadata and
411491
force-push the proposal.
412492

493+
<details>
494+
<summary>Security release</summary>
495+
496+
If there are private security patches, remember to push and open the proposal
497+
in the `nodejs-private` GitHub repository.
498+
499+
</details>
500+
413501
### 7. Ensure that the release branch is stable
414502

415503
Run a **[`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)**
@@ -425,6 +513,15 @@ purpose. Run it once with the base `vx.x` branch as a reference and with the
425513
proposal branch to check if new regressions could be introduced in the
426514
ecosystem.
427515

516+
<details>
517+
<summary>Security release</summary>
518+
519+
If there are private security patches, do not run any CI jobs on the proposal
520+
until CI has been locked down. The security steward should be coordinating this
521+
with the Build Working Group.
522+
523+
</details>
524+
428525
### 8. Produce a nightly build _(optional)_
429526

430527
If there is a reason to produce a test release for the purpose of having others
@@ -437,6 +534,13 @@ enter a proper length commit SHA, enter a date string, and select "nightly" for
437534
This is particularly recommended if there has been recent work relating to the
438535
macOS or Windows installers as they are not tested in any way by CI.
439536

537+
<details>
538+
<summary>Security release</summary>
539+
540+
Do not produce a release candidate build.
541+
542+
</details>
543+
440544
### 9. Produce release builds
441545

442546
Use **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** to
@@ -555,6 +659,26 @@ $ git rebase v1.x
555659
$ git push upstream v1.x-staging
556660
```
557661

662+
<details>
663+
<summary>Security release</summary>
664+
665+
For security releases, you can start merging the release in the `nodejs-private`
666+
GitHub organisation in advance by following the same steps:
667+
668+
```console
669+
$ git checkout v1.x
670+
$ git merge --ff-only v1.2.3-proposal
671+
$ git push private v1.x
672+
$ git checkout v1.x-staging
673+
$ git rebase v1.x
674+
$ git push private v1.x-staging
675+
```
676+
677+
Once all releasers are ready, you can push each of the branches to the public
678+
repository.
679+
680+
</details>
681+
558682
### 13. Cherry-pick the release commit to `main`
559683

560684
```console
@@ -585,6 +709,27 @@ $ git push upstream main
585709

586710
**Do not** cherry-pick the "Working on vx.y.z" commit to `main`.
587711

712+
<details>
713+
<summary>Security release</summary>
714+
715+
For security releases, you will also need to land the fixes on the `main`
716+
branch (if they apply there). Often, you can just cherry-pick the same commit
717+
that landed in the `current` security release which should already have the
718+
metadata.
719+
720+
It is useful to first push the patches to `private/main` to check that the
721+
GitHub actions runs pass, before pushing to `upstream/main`:
722+
723+
```console
724+
$ git checkout main
725+
$ git reset --hard upstream/main
726+
$ git cherry-pick ... # apply the patches which apply to main
727+
$ git push private main # push to private main first run GitHub actions
728+
$ git push upstream main
729+
```
730+
731+
</details>
732+
588733
### 14. Push the release tag
589734

590735
Push the tag to the repository before you promote the builds. If you
@@ -744,6 +889,13 @@ announcements.
744889

745890
Ping the IRC ops and the other [Partner Communities][] liaisons.
746891

892+
<details>
893+
<summary>Security release</summary>
894+
895+
Let the security release steward know the releases are available.
896+
897+
</details>
898+
747899
### 21. Celebrate
748900

749901
_In whatever form you do this..._

0 commit comments

Comments
0 (0)
You are visitor 01402503 — 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.