Timeline for What is best practice for handling PRs addressing security vulnerabilities in public repo?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 7, 2017 at 22:12 | vote | accept | Joe Murray | ||
| Oct 18, 2017 at 22:16 | vote | accept | Joe Murray | ||
| Nov 7, 2017 at 22:12 | |||||
| Oct 17, 2017 at 14:18 | comment | added | Martin Spamer | IMHO there is more to be gained by making all bugs shallow, than the risk of reverse engineering an exploit from a pull request for a security patch. | |
| Oct 5, 2017 at 17:47 | answer | added | Lloyd Moore | timeline score: 2 | |
| Oct 4, 2017 at 19:28 | history | edited | Joe Murray | CC BY-SA 3.0 |
removed extraneous word, travels
|
| Sep 28, 2017 at 19:02 | comment | added | Joe Murray | We follow the fairly common practice of a regularly scheduled release window for security matters so that user orgs can be ready. I think there may have been one or two exceptions, but it seems to work better for us. | |
| Sep 28, 2017 at 14:57 | comment | added | Jory Geerts | This question seems to assume that, as long as the security issue is not disclosed by the team, it is unknown to the world. That is simply not true; any security issue that is discovered should be assumed to be known about by someone with bad intentions somewhere. Now, if you assume that somebody else already knows about the issue and might be exploiting it, you can no longer postpone the release of the fix until your regular monthly release. You must release ASAP. That means there is no problem with following the regular PR flow. Just PR against the latest release branch, merge, tag, release. | |
| Sep 27, 2017 at 16:08 | comment | added | user251748 | Open Source is the new attack vector, I guess. If you can't beat em, join em and then beat em. Can you create secure systems in an open environment? Can you do it in a closed environment? | |
| Sep 19, 2017 at 22:41 | comment | added | mrr | Full immediate disclosure (i.e. public disclosure with no delay) is a perfectly legitimate thing to do. | |
| Sep 18, 2017 at 23:21 | comment | added | Joe Murray | Github does provide private repos that can be selectively opened to secteam invitees. Not sure if that exists for forks...I suspect not. | |
| Sep 18, 2017 at 18:58 | comment | added | Emerson Cardoso | In my opinion, if you need some part of your process to be private, then it should be done outside of GitHub (because GH is public); after this specific part is done and everyone reviewed its code; you can create a PR on GH that will be merged as quick as possible, just to 'return' to the official process. You could use another tool to manage those exceptions in the process. | |
| Sep 18, 2017 at 17:11 | review | Close votes | |||
| Sep 23, 2017 at 3:03 | |||||
| Sep 18, 2017 at 16:58 | comment | added | Joe Murray | Most issues are reported by others, but probably less than a fifth of fixes come from those not on the security team. | |
| Sep 18, 2017 at 16:38 | comment | added | Berin Loritsch | I'm not sure if there is a best practice set up. GitLab is essentially a private GitHub. Balancing the concerns of open source and security fixes is not easy. How many of your security fixes come from people not on your security team? | |
| Sep 18, 2017 at 16:37 | history | tweeted | twitter.com/StackSoftEng/status/909818765860392971 | ||
| Sep 18, 2017 at 15:37 | history | edited | Thomas Owens♦ | CC BY-SA 3.0 |
deleted 172 characters in body
|
| Sep 18, 2017 at 15:36 | review | First posts | |||
| Sep 19, 2017 at 19:07 | |||||
| Sep 18, 2017 at 15:31 | history | asked | Joe Murray | CC BY-SA 3.0 |