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