The thinking is that on a security issue, we do not want a patch to come in through a Pull request, nor do we want to have comments on security issues on Github. The suggestion is that security patches should be attached to Jiras and all the review should be done through Jira or Crucible. After receiving the go ahead on the Jira ticket then the patch should be pushed directly into origin to avoid a pull request, since pull requests get a lot of attention.
Make a Security JIRA - If there isa patch attach it to the JIRA
- Discuss the issue and test the patch in JIRA
- At the point where we agree on the patch - then generate the PR and immediately merge it.
...
Two best options for applying a security patch directly?
- Get a private fork on github ($$) where the security group could have all pull-requests that
...
- can
...
- not be seen from the outside and
...
- frequently get
...
- synched to the main
...
- repo.
...
- When applying the patch, apply directly into origin to avoid a pull request. One can do this using the following:
| Code Block | ||||
|---|---|---|---|---|
| ||||
git commit --author=" |
...
Joe Smith <joe.smith@genericinstitution.edu>" |
When pushed
...
, Git will have an entry for the author, as specified explicitly above, and the committer, whoever pushes in the patch.
Before the patch is ready
- Open a Security JIRA
- Unlike a typical patch that would go directly into a PR (pull request), the patch will be attached to the JIRA for review. Hence the need to apply the patch directly.