FYI, the security@golang.org email address already exists.

It's mentioned here and in the main repo's CONTRIBUTING.md file.

A security problem that is being actively exploited and must be addressed immediately.

Would an actively exploited security problem in the standard library or gc toolchain thus automatically trigger a point release? Releases, even minor ones, are a fair amount of work. At the very least, I think we'd want to say something about severity here, which is orthogonal to active exploitation.

I think if it's not worth issuing a point release for, then it's "not a security problem" aka bullet 1.

Also note that I've omitted any mention of "early partner disclosure". This means the policy would not allow for notification of packagers or binary distributions. Based on my discussions with the security teams that put together the Chrome, Android, Dart and Angular security policies, these advanced disclosures have a very high chance of becoming public and causing more damage.

Their recommendation was simple to issue a statement, upon receipt of the security issue, that "We are planning to release version x.y.z on date YYYY-MM-DD. We recommend that all users upgrade to this release when it becomes available."

@josharian I agree that severity and urgency should be treated separately.

Perhaps something along the lines of:

Security issues will be ranked according to their severity [S1-S3]
S1 - Would allow remote execution of code or privilege escalation via running Go programs
S2
S3 - Requires modification to source to be exploited

Urgency [U1-U3]
U1 - Is being actively exploited
U2
U3 - No known exploits in the wild

Along with a guideline that a point release would normally be made for issues with either S1 or U1, or S2 and U2.

See also http://www.rust-lang.org/security.html, as well as the back discussion in https://internals.rust-lang.org/t/proposed-security-disclosure-policy/2024

sparklemotion/nokogiri#1191 also has some other useful info.

Thanks for the links - give me a bit to review.

@reedloden - I definitely like the Rust policy - http://www.rust-lang.org/security.html

The python equivalent - https://www.python.org/news/security/ - is a little too glib for my liking. The WebKit policy - https://www.webkit.org/security/ - includes a process for becoming a member of the security review team, which is interesting, but probably too much for our needs (IMO).

The Xen Project - http://www.xenproject.org/security-policy.html - also contains an official embargo process, which I would prefer to avoid.

Are there others that we should be evaluating? I'm inclined to start with the Rust policy as a template, and customize slightly for Go.

@adg - could I get your arbiter stamp of approval to proceed with a first draft of a policy, based on Rust, that would eventually be hosted at:

http://golang.org/security

@jbuberel, there's also http://rubyonrails.org/security/ (text seems mostly the same as some of the others [includes EOL info], though they use https://hackerone.com for submissions rather than a security@ address).

Glad to see you guys getting a policy in place. :)

@reedloden I did take a look through the hackerone.com product. I've never used it before and it does look interesting. But given that the Go project doesn't exactly have budget for bug bounties, it seems like a bit more than we need. Thoughts?

@jbuberel LGTM for a policy based on the Rust one.

On 30 July 2015 at 11:59, Jason Buberel notifications@github.com wrote:

@reedloden https://github.com/reedloden I did take a look through the
hackerone.com product. I've never used it before and it does look
interesting. But given that the Go project doesn't exactly have budget for
bug bounties, it seems like a bit more than we need. Thoughts?

—
Reply to this email directly or view it on GitHub
#11502 (comment).

@jbuberel -- HackerOne isn't just for bug bounties (seems to be a common misconception), and plenty of open source projects use the platform (for free) without paying any bounties at all. It's just a great way to manage incoming reports, interact with the researcher(s), and handle public disclosure in the end. I've always felt that security@ mailboxes are terrible, as it just makes it so difficult to keep up with things, see the current status of issues, and make sure everybody is on the same page. IMHO, the platform speaks for itself, so just take a look at some of the publicly disclosed reports on https://hackerone.com/rails to see how it works in action.

Disclaimer: I lead security for HackerOne. Doing my best not to be sales-y at all here (I truly feel the platform works great for dealing with incoming security reports). However, the main thing is just to have a defined process that works for everybody and is followed. Whether that's just some private e-mail address or use of some platform or whatever in the end.

Happy to help in any way I can... As I said, security is my full-time job, so used to dealing with this stuff and helping out other companies and OSS projects figure out something that works for them.

We've been burned enough by services both going away and changing on us. Email may not be ideal in all respects, but it works, has been around for awhile, should survive a bit longer, and people on both sides know how to use it.

@reedloden, HackerOne's terms are completely at odds with the coordinated disclosure process which has evolved over the years. HackerOne assumes control over the process, which is completely impossible if we are dealing with a cross-vendor issue.

@fweimer, not sure where you're getting that, but none of that is true at all. Perhaps thinking of one of our competitors? Happy to discuss further off this thread. Feel free to drop me a note at reed [@] hackerone.com.

Anyway, my comments have derailed this issue way too much, and I do apologize. I only explained stuff about HackerOne because @jbuberel asked for my thoughts.

Would like to bring the conversation back to focusing on getting Go a vulnerability response policy that works for everybody and ensures all the right things are done. Sounds like people feel Rust's policy is a good start, so seems like getting a draft together based on that would be a reasonable next step. Happy to help with that if needed.

@jbuberel, I expect most GNU/Linux distributions would be fine if Rust adopted the Go process, maybe with the caveat that it might be a bit inconvenient if the 72 hour pre-disclosure period includes a weekend.

CL submitted for the proposal, with a full draft of the actual policy here:

https://go-review.googlesource.com/#/c/13007

@jbuberel, the CL seems garbled/word-wrapped, destroying the markup.

I think the claim that embargoes are not working due to leaks does not work out in practice. Short embargoes are generally unproblematic. Notifying the private distros list on the same day as the commit does not make sense, you can just wait for the commit and notify the public oss-security list.

You really should add security-related regression tests to the public test suite, which means you have to reveal details about exploitation. This also helps those (like Debian) who have to keep alive older branches much longer than you do.

The bigger challenge is to consistently identify fixes as security-relevant if they stem from a non-security bug report. (This is what large projects like Linux, LibreOffice, and smaller ones such as GNU libc are struggling with.) Maybe the policy could say something about that.

CL https://golang.org/cl/13007 mentions this issue.

@fweimer I blame SublimeText for not properly wrapping. A new patchset will be uploaded shortly to address that. Sorry!

Regarding the early disclosure and embargo, if I understand you correctly, you are suggesting the following process:

1. Notification is received, threat analyzed.
2. Fixes are created, but patches are not committed to the public repo.
3. Send email to distros@openwall with details and patch contents.
4. Wait 72 hours (or 3 business days, etc.)
5. Commit patches to public repo, upload new binary builds
6. Send public announcement.

Regarding the problem of identifying security-relevant issues, I added a section (below). Let me know if you think that is sufficient.

Flagging Existing Issues as Security-relevant

If any member of the community believes that an existing issue is security-relevant, we ask that they send an email to security@golang.org. The email should include the issue ID and a short description of why it should be handled according to this security policy.

@jbuberel, the list of six steps matches more closely what many mature upstream projects currently do.

On the other hand, many Go users will have to recompile their application anyway and cannot simply run yum upgrade or apt-get update && apt-get dist-upgrade to apply the fixes to their systems, which means that maybe the pre-notification is less relevant in the Go context.

Personally, I would suggest to try the three-day-embargo for a while, see how it works, and make adjustments as necessary.

@fweimer, sounds reasonable to me. Third patch set uploaded to include a "3 business day" embargo before the public announcements are made.

Jason's proposal is available for review here: https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md

Anyway to set up a security announcement list? Having to subscribe to
golang-dev seems awkward.

On Tuesday, August 4, 2015, Andrew Gerrand notifications@github.com wrote:

Jason's proposal is available for review here:
https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md

—
Reply to this email directly or view it on GitHub
#11502 (comment).

We already have golang-announce. Would that suffice ?

On Wed, Aug 5, 2015 at 11:31 AM, Reed Loden notifications@github.com
wrote:

Anyway to set up a security announcement list? Having to subscribe to
golang-dev seems awkward.

On Tuesday, August 4, 2015, Andrew Gerrand notifications@github.com
wrote:

Jason's proposal is available for review here:

https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md

—
Reply to this email directly or view it on GitHub
#11502 (comment).

—
Reply to this email directly or view it on GitHub
#11502 (comment).

Nope. That's fine. golang-dev is specifically called out in the proposal.
Seems like that should focus on golang-announce (and also send a notice to
golang-dev and golang-nuts).

On Tuesday, August 4, 2015, Dave Cheney notifications@github.com wrote:

We already have golang-announce. Would that suffice ?

On Wed, Aug 5, 2015 at 11:31 AM, Reed Loden <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

Anyway to set up a security announcement list? Having to subscribe to
golang-dev seems awkward.

On Tuesday, August 4, 2015, Andrew Gerrand <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

Jason's proposal is available for review here:

https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md

—
Reply to this email directly or view it on GitHub
#11502 (comment).

—
Reply to this email directly or view it on GitHub
#11502 (comment).

—
Reply to this email directly or view it on GitHub
#11502 (comment).

@reedloden Agreed - golang-announce@ should be used instead. I'll update the proposal to reflect that.

@jbuberel It may also make sense to request the CVE ID via the distros list (or privately from Debian or Red Hat, if you'd prefer that), otherwise you will have to wait for assignment from other sources.

@fweimer Good suggestion. I'll update the proposal to specify that list for CVE-ID requests.

@jbuberel in case you missed it, I pointed out a small typo in the CL (after it was merged)

@mpl Yep, I saw that and have updated my local copy to include the fix. I send a new patch under a new CL shortly with a few additional fixes/changes.

Next CL:
https://go-review.googlesource.com/13283

CL https://golang.org/cl/13283 mentions this issue.

We're getting close to the final version - please take one last look:

https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md

If there is no additional changes to be made, the "Implementation" section will be HTML-ified and posted at golang.org/security.

@jbuberel Minor typo: “and the oss-security@openwall” should be “and oss-security@openwall”. Otherwise, looks reasonable.

@fweimer - fixed

CL https://golang.org/cl/13955 mentions this issue.