Skip to content

Commit d979d54

Browse files
committed
doc: include security release proposal tutorial
1 parent b993789 commit d979d54

File tree

1 file changed

+124
-0
lines changed

1 file changed

+124
-0
lines changed

doc/contributing/security-release-process.md

Lines changed: 124 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -190,6 +190,130 @@ out a better way, forward the email you receive to
190190
[Security release stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards).
191191
If necessary add the next rotation of the steward rotation.
192192

193+
***
194+
195+
## Creating proposal
196+
197+
The process to create a proposal for a Security Release is very similar to the
198+
common release lines. The major difference is that the base repository is [`node-private`](https://github.com/nodejs-private/node-private)
199+
instead of [`node`](https://github.com/nodejs/node).
200+
201+
Once the [previous steps](#planning) were completed, you should be able to
202+
create a proposal against `node-private`.
203+
204+
### Step 1 - Sync vXX.x-staging branch
205+
206+
The first step is to make sure that the
207+
`origin`[\[1\]](#glossary)/`vXX.x-staging`[\[2\]](#glossary) branch is updated:
208+
209+
```console
210+
$ git remote -v
211+
origin [email protected]:nodejs-private/node-private.git (fetch)
212+
origin [email protected]:nodejs-private/node-private.git (push)
213+
upstream [email protected]:nodejs/node.git (fetch)
214+
upstream [email protected]:nodejs/node.git (push)
215+
$ git remote update upstream
216+
$ git reset --hard upstream/vXX.x
217+
```
218+
219+
### 2. Create a new branch for the release
220+
221+
Then as usual, create the proposal branch:
222+
223+
```console
224+
$ git checkout -b vXX.X.X-proposal
225+
```
226+
227+
### 3. Land all the PRs on your proposal branch
228+
229+
**Important**: if you are using `git cherry-pick $SHA1` you will need to
230+
manually add the `Reviewed-By` and `PR-URL`
231+
metadata as `git node land` doesn't work on `node-private`.
232+
233+
```console
234+
$ git cherry-pick 1b27a7152309aa87993596f3802d472dcb15f439
235+
$ git commit --amend
236+
237+
# add metadata
238+
$ git push origin vXX.X.X-proposal # IMPORTANT: origin is `node-private` not a public fork
239+
```
240+
241+
### 4. Update `src/node_version.h`
242+
243+
See: [releases.md](./releases.md#3-update-srcnode_versionh)
244+
245+
### 5. Update the changelog
246+
247+
See: [releases.md](./releases.md#4-update-the-changelog)
248+
249+
**Note**: make sure to include the right entry to the `CHANGELOG_Vx.md`.
250+
251+
The new entry should take the following form:
252+
253+
```markdown
254+
<a id="x.y.x"></a>
255+
## YYYY-MM-DD, Version x.y.z (Release Type), @releaser
256+
257+
This is a security release.
258+
259+
### Notable changes
260+
261+
* List interesting changes here
262+
* Particularly changes that are responsible for minor or major version bumps
263+
* Also be sure to look at any changes introduced by dependencies such as npm
264+
* ... and include any notable items from there
265+
266+
### Commits
267+
268+
* Include the full list of commits since the last release here. Do not include "Working on X.Y.Z+1" commits.
269+
```
270+
271+
### 6. Create release commit
272+
273+
The `CHANGELOG.md`, `doc/changelogs/CHANGELOG_Vx.md`, `src/node_version.h`, and
274+
`REPLACEME` changes should be the final commit that will be tagged for the
275+
release. When committing these to git, use the following message format:
276+
277+
```text
278+
YYYY-MM-DD, Version x.y.z (Release Type)
279+
This is a security release.
280+
Notable changes:
281+
* Copy the notable changes list here, reformatted for plain-text
282+
PR-URL: TBD
283+
```
284+
285+
### 7. Propose release on GitHub
286+
287+
Push the release branch to `nodejs-private/node-private`, not to your own fork.
288+
This allows release branches to more easily be passed between members of the
289+
release team if necessary.
290+
291+
Create a pull request targeting the correct release line. For example, a
292+
`v5.3.0-proposal` PR should target `v5.x`, not `main`. Paste the CHANGELOG
293+
modifications into the body of the PR so that collaborators can see what is
294+
changing. These PRs should be left open for at least 24 hours, and can be
295+
updated as new commits land. If the CHANGELOG pasted into the pull request
296+
is long enough that it slows down the GitHub UI, consider pasting the commits
297+
into `<details>` tags or in follow up comments.
298+
299+
If using the `<details>` tag, use the following format:
300+
301+
```markdown
302+
<details>
303+
<summary>Commits</summary>
304+
305+
* Full list of commits...
306+
</details>
307+
```
308+
309+
If you need any additional information about any of the commits, this PR is a
310+
good place to @-mention the relevant contributors.
311+
312+
After opening the PR, update the release commit to include `PR-URL` metadata and
313+
force-push the proposal.
314+
315+
***
316+
193317
[H1 CVE requests]: https://hackerone.com/nodejs/cve_requests
194318
[docker-node]: https://github.com/nodejs/docker-node/issues
195319
[email]: https://groups.google.com/forum/#!forum/nodejs-sec

0 commit comments

Comments
 (0)