@@ -190,6 +190,130 @@ out a better way, forward the email you receive to
190
190
[ Security release stewards] ( https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards ) .
191
191
If necessary add the next rotation of the steward rotation.
192
192
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
+
193
317
[ H1 CVE requests ] : https://hackerone.com/nodejs/cve_requests
194
318
[ docker-node ] : https://github.com/nodejs/docker-node/issues
195
319
[ email ] : https://groups.google.com/forum/#!forum/nodejs-sec
0 commit comments