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.
It's actually possible to give credit when applying a patch which you
then push to origin.
git commit --author="D. Stuart Freeman <stuart.freeman@et.gatech.edu>"
When pushed will show me as the "author" and whoever ran that command as the "commiter".
I'm not saying whether this is a better option than the other
suggestions, just that it's available.
It's also possible to have a private fork of the repo (paid on github or
free on bitbucket) where the security group could have pull-requests that
can't be seen from the outside and eventually get synced to the main
repo.
then push to origin.
git commit --author="D. Stuart Freeman <stuart.freeman@et.gatech.edu>"
When pushed will show me as the "author" and whoever ran that command as the "commiter".
I'm not saying whether this is a better option than the other
suggestions, just that it's available.
It's also possible to have a private fork of the repo (paid on github or
free on bitbucket) where the security group could have pull-requests that
can't be seen from the outside and eventually get synced to the main
repo.
It's actually possible to give credit when applying a patch which you
then push to origin.
git commit --author="D. Stuart Freeman <stuart.freeman@et.gatech.edu>"
When pushed will show me as the "author" and whoever ran that command as the "commiter".
I'm not saying whether this is a better option than the other
suggestions, just that it's available.
It's also possible to have a private fork of the repo (paid on github or
free on bitbucket) where the security group could have pull-requests that
can't be seen from the outside and eventually get synced to the main
repo.
then push to origin.
git commit --author="D. Stuart Freeman <stuart.freeman@et.gatech.edu>"
When pushed will show me as the "author" and whoever ran that command as the "commiter".
I'm not saying whether this is a better option than the other
suggestions, just that it's available.
It's also possible to have a private fork of the repo (paid on github or
free on bitbucket) where the security group could have pull-requests that
can't be seen from the outside and eventually get synced to the main
repo.
Let's also not forget that patches over email were well supported in Git history. The format-patch and am commands are geared specifically around this workflow. Instead of saving a diff manually into an arbitrarily named file, format-patch creates the file (or a sequence) with authorship and commit message intact.
This is basically an out of band pull request (merge request, really) that automates the patch application and commit-with-other-author process. A regular commit --amend will allow editing or sanitizing the commit message without changing the author. Very easy to use and gives a nice workflow over an abstract transport protocol (email, JIRA attachment, flash drive, punch card).
This is basically an out of band pull request (merge request, really) that automates the patch application and commit-with-other-author process. A regular commit --amend will allow editing or sanitizing the commit message without changing the author. Very easy to use and gives a nice workflow over an abstract transport protocol (email, JIRA attachment, flash drive, punch card).
I'm very much in favour of keeping security issues out of the github
pull requests and using git patches or reminding people to supply an
author with their commit.
The security issues will still stand out a little bit as they won't go
through the pull request mechanic, but they often did in SVN as they
didn't have any commit message apart from the SAK number.
Remember that once you push something to github it's public and
probably indexed on someone elses server as well:
http://jordan-wright.github.io/blog/2014/12/30/why-deleting-sensitive-information-from-github-doesnt-save-you/
pull requests and using git patches or reminding people to supply an
author with their commit.
The security issues will still stand out a little bit as they won't go
through the pull request mechanic, but they often did in SVN as they
didn't have any commit message apart from the SAK number.
Remember that once you push something to github it's public and
probably indexed on someone elses server as well:
http://jordan-wright.github.io/blog/2014/12/30/why-deleting-sensitive-information-from-github-doesnt-save-you/