T0b1/wasmtime
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update security release documentation slightly (#5940)

Browse Source 
This modernizes our process doc a bit with what I've been doing for the
last security release and the upcoming one as well.
This commit is contained in:
Alex Crichton
2023-03-06 11:19:53 -06:00
committed by GitHub
parent 18ee645ebe
commit 3782ce7333
1 changed files with 15 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
docs/contributing-release-process.md
View File

@@ -132,28 +132,31 @@ the runbook is merged.
Advisory** Advisory**
* This will not have any CI run, it's recommended to run `./ci/run-tests.sh` * This will not have any CI run, it's recommended to run `./ci/run-tests.sh`
locally at least. locally at least.
* This will also only be the patch for the `main` branch. You'll need to * Develop fixes for all branches that will get a patch release in the
locally maintain and develop patches for any older releases being backported advisory, one PR per branch. When the advisory is published all branches
to. Note that from the major release process there should already be a will be merged simultaneously. Be sure to run `./ci/run-tests.sh` in each
branch for all older releases. branch.
* Don't forget to update `RELEASES.md` with notes about the release on
each branch.
2. **Send a PR for the version bump when an email goes out announcing there will 2. **Send a PR for the version bump when an email goes out announcing there will
be a security release** be a security release**
* An email is sent to the bytecodealliance security mailing list ahead of a * An email is sent to the bytecodealliance security mailing list ahead of a
patch release to announce that a patch release will happen. At this time you patch release to announce that a patch release will happen. At this time you
should [trigger the version bump][ci-trigger] against the appropriate should [trigger the version bump][ci-trigger] against the appropriate
`release-x.y.z` branch with the `release-patch` argument. `release-x.y.z` branches with the `release-patch` argument.
* This will send a PR, but you should not merge it. Instead use this PR and * This will send a PR, but you should not merge it. Instead use this PR and
the time ahead of the security release to fix any issues with CI. Older the time ahead of the security release to fix any issues with CI. Older
`release-x.y.z` branches haven't run CI in awhile so they may need to `release-x.y.z` branches haven't run CI in awhile so they may need to
backport fixes of one variety or another. DO NOT include the actual fix for backport fixes of one variety or another. DO NOT include the actual fix for
the security issue into the PR, that comes in the next step. the security issue into the PR, that comes in the next step.
3. **Make the patches public** 3. **Make the advisories/patches public**
* For the `main` branch this will involve simply publishing the GitHub * Publishing the GitHub Security Advisory will merge all the PRs into each
Security Advisory. Note that CI will run after the advisory's changes are branch from the advisory. Note that CI will run for release branches but
merged in on `main`. `main` will probably fail CI since it expected to be merged through the
* For the backported release branches you should either create a PR targeting merge queue, but that's ok.
these branches or push the changes to the previous version-bump PRs. * Double-check that CI for release branches finishes and completes
3. **Merge the version-bump PR** successfully.
4. **Merge the version-bump PR**
* Like the patch release process this will kick everything else into motion. * Like the patch release process this will kick everything else into motion.
Note that the actual security fixes should be merged either before or as Note that the actual security fixes should be merged either before or as
part of this PR. part of this PR.