| # Proposal: Security Policy for Go |
| |
| Author(s): Jason Buberel |
| |
| Last updated: 2015-07-31 |
| |
| Discussion at https://golang.org/issue/11502. |
| |
| ## Abstract |
| |
| Go programs are being deployed as part of security-critical applications. |
| Although Go has a generally good history of being free of security |
| vulnerabilities, the current process for handling security issues is very |
| informal. In order to be more transparent and the better coordinate with the |
| community, I am proposing that the Go project adopt a well-defined security |
| and vulnerability disclosure policy. |
| |
| ## Background |
| |
| The Go standard library includes a complete, modern [cryptography |
| package](https://golang.org/pkg/crypto/). Since the initial release of Go, |
| there has a single documented security vulnerability [CVE-2014-7189] |
| (https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7189) in the crypto |
| package. This is a promising track record, but as Go usage increases the |
| language and standard library will come under increasing scrutiny by the |
| security research community. |
| |
| In order to better manage security issues, a formal security policy for Go |
| should be established. |
| |
| Other language and library open source projects have established security |
| policies. The following policies were reviewed and considered in the creation |
| of this proposal: |
| |
| * [Python Security Policy](https://www.python.org/news/security/) |
| * [Ruby on Rails Security Policy](http://rubyonrails.org/security/) |
| * [Rust Security Policy](https://www.rust-lang.org/security.html) |
| * [Webkit Security Policy](https://www.webkit.org/security/) |
| * [Xen Project Security Policy](https://www.xenproject.org/security-policy.html) |
| |
| These policies differ in various aspects, but in general there is a common set |
| of guidelines that are typically established: |
| |
| * How security issues should be reported |
| * Who will be responsible for reviewing these reports |
| * What is the response time promises made for initial review |
| * Exactly what steps will be followed for handing issues |
| * What type of embargo period will be applied |
| * How will communication of issues be handled, both pre- and post-disclosure |
| |
| It was also suggested that the Go project consider the use of managed security |
| services, such as [HackerOne](https://hackerone.com/). The consensus of |
| commenters on this topic was a reluctance to base the Go process on a third- |
| party system at this time. |
| |
| |
| ## Proposal |
| |
| Among the existing security policies reviewed, the [Rust |
| policy](https://www.rust-lang.org/security.html) is considered a good starting |
| point. Once adopted, this policy will be hosted at |
| [https://golang.org/security](https://golang.org/security). The details of the |
| policy are in the Implementation section below. |
| |
| ## Implementation |
| |
| ### Reporting a Security Bug |
| |
| Safety is one of the core principles of Go, and to that end, we would like to |
| ensure that Go has a secure implementation. Thank you for taking the time to |
| responsibly disclose any issues you find. |
| |
| All security bugs in the Go distribution should be reported by email to |
| [security@golang.org](mailto:security@golang.org). This list is delivered to a |
| small security team. Your email will be acknowledged within 24 hours, and |
| you'll receive a more detailed response to your email within 72 hours |
| indicating the next steps in handling your report. If you would like, you can |
| encrypt your report using our PGP key (listed below). |
| |
| Please use a descriptive subject line for your report email. After the initial |
| reply to your report, the security team will endeavor to keep you informed of |
| the progress being made towards a fix and full announcement. As recommended by |
| RFPolicy, these updates will be sent at least every five days. In reality, |
| this is more likely to be every 24-48 hours. |
| |
| If you have not received a reply to your email within 48 hours, or have not |
| heard from the security team for the past five days, please contact the |
| following members of the Go security team directly: |
| |
| * Contact the primary security coordinator - [Andrew Gerrand] |
| (mailto:adg@golang.org) - directly. |
| * Contact the secondary coordinator - [Adam Langley](mailto:agl@google.com) - |
| [public key](https://www.imperialviolet.org/key.asc) directly. |
| * Post a message to [golang-dev@golang.org](mailto:golang-dev@golang.org) or |
| [golang-dev web interface] |
| (https://groups.google.com/forum/#!forum/golang-dev). |
| |
| Please note that golang-dev@golang.org is a public discussion forum. When |
| escalating on this list, please do not disclose the details of the issue. |
| Simply state that you're trying to reach a member of the security team. |
| |
| ### Flagging Existing Issues as Security-related |
| |
| If you believe that an [existing issue](https://github.com/golang/go/issues) |
| is security-related, we ask that you send an email to |
| [security@golang.org](mailto: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. |
| |
| ### Disclosure Process |
| |
| The Go project will use the following disclosure process: |
| |
| 1. Once the security report is received it will be assigned a primary handler. |
| This person will coordinate the fix and release process. |
| 1. The problem will be confirmed and a list of all affected versions is |
| determined. |
| 1. Code will be audited to find any potential similar problems. |
| 1. If it is determined, in consultation with the submitter, that a CVE-ID is |
| required the primary handler will be responsible for obtaining via email |
| to the [oss-distros] |
| (http://oss-security.openwall.org/wiki/mailing-lists/distros) list. |
| 1. Fixes will be prepared for the current stable release and the head/master |
| revision. These fixes will not be committed to the public repository. |
| 1. Details of the issue and patch files will be sent to the |
| [distros@openwall] |
| (http://oss-security.openwall.org/wiki/mailing-lists/distros) |
| mailing list. |
| 1. Three working days following this notification, the fixes will be |
| applied to the [public repository](https://go.googlesource.com/go) and new |
| builds deployed to [https://golang.org/dl](https://golang.org/dl) |
| 1. On the date that the fixes are applied, announcements will be sent to |
| [golang-announce] |
| (https://groups.google.com/forum/#!forum/golang-announce), |
| [golang-dev@golang.org](https://groups.google.com/forum/#!forum/golang-dev), |
| [golang-nuts@golang.org](https://groups.google.com/forum/#!forum/golang-nuts) |
| and the [oss-security@openwall](http://www.openwall.com/lists/oss-security/). |
| 1. Within 6 hours of the mailing lists being notified, a copy of the advisory |
| will also be published on the [Go blog](https://blog.golang.org). |
| |
| This process can take some time, especially when coordination is required with |
| maintainers of other projects. Every effort will be made to handle the bug in |
| as timely a manner as possible, however it's important that we follow the |
| release process above to ensure that the disclosure is handled in a consistent |
| manner. |
| |
| For those security issues that include the assignment of a CVE-ID, the issue |
| will be publicly listed under the ["Golang" product on the CVEDetails |
| website] |
| (http://www.cvedetails.com/vulnerability-list/vendor_id-14185/Golang.html) |
| as well as the [National Vulnerability Disclosure site] |
| (https://web.nvd.nist.gov/view/vuln/search). |
| |
| ### Receiving Security Updates |
| |
| The best way to receive security announcements is to subscribe to the |
| [golang-announce] |
| (https://groups.google.com/forum/#!forum/golang-announce) |
| mailing list. Any messages pertaining to a security issue will be prefixed |
| with `[security]`. |
| |
| ### Comments on This Policy |
| |
| If you have any suggestions to improve this policy, please send an email to |
| [golang-dev@golang.org](mailto:golang-dev@golang.org) for discussion. |
| |
| ### Plaintext PGP Key for [security@golang.org](mailto:security@golang.org) |
| |
| ``` |
| -----BEGIN PGP PUBLIC KEY BLOCK----- |
| Comment: GPGTools - https://gpgtools.org |
| |
| mQINBFXI1h0BEADZdm05GDFWvjmQKutUVb0cJKS+VR+6XU3g/YQZGC8tnIL6i7te |
| +fPJHfQc2uIw0xeBgZX4Ni/S8yIqsbIjqYeaToX7QFUufJDQwrmlQRDVAvvT5HBT |
| J80JEs7yHRreFoLzB6dnWehWXzWle4gFKeIy+hvLrYquZVvbeEYTnX7fNzZg0+5L |
| ksvj7lnQlJIy1l3sL/7uPr9qsm45/hzd0WjTQS85Ry6Na3tMwRpqGENDh25Blz75 |
| 8JgK9JmtTJa00my1zzeCXU04CKKEMRbkMLozzudOH4ZLiLWcFiKRpeCn860wC8l3 |
| oJcyyObuTSbr9o05ra3On+epjCEFkknGX1WxPv+TV34i0a23AtuVyTCloKb7RYXc |
| 7mUaskZpU2rFBqIkzZ4MQJ7RDtGlm5oBy36j2QL63jAZ1cKoT/yvjJNp2ObmWaVF |
| X3tk/nYw2H0YDjTkTCgGtyAOj3Cfqrtsa5L0jG5K2p4RY8mtVgQ5EOh7QxuS+rmN |
| JiA39SWh7O6uFCwkz/OCXzqeh6/nP10HAb9S9IC34QQxm7Fhd0ZXzEv9IlBTIRzk |
| xddSdACPnLE1gJcFHxBd2LTqS/lmAFShCsf8S252kagKJfHRebQJZHCIs6kT9PfE |
| 0muq6KRKeDXv01afAUvoB4QW/3chUrtgL2HryyO8ugMu7leVGmoZhFkIrQARAQAB |
| tCZHbyBTZWN1cml0eSBUZWFtIDxzZWN1cml0eUBnb2xhbmcub3JnPokCPQQTAQoA |
| JwUCVcjWHQIbAwUJB4YfgAULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRA6RtGR |
| eVpYOLnDD/9YVTd6DTwdJq6irVfM/ICPlPTXB0JLERqCI1Veptcp56eQoJ0XWGQp |
| tkGlgbvmCzFo0B+65Te7YA4R3oyBCXd6JgyWQQPy5p60FHyuuCPVAReclSWyt9f2 |
| Yj/u4DjghKhELOvPiI96egcU3g9jrEEcPjm7JYkc9M2gVSNOnnJvcD7wpQJNCzon |
| 51eMZ1ZyfA5UCBTa0SaT9eXg5zwNlYQnB6ZF6TjXezkhLqlTsBuHxoNVf+9vCC0o |
| ZKIM2ovptMx9eEguTDKWaQ7tero7Zs/q5fwk/MDzM/LGJ9aXy2RCtqBxv46vDS7G |
| fCNq+aPD/wyFd6hxQkvkua6hgZwYT+cJWHYA2Yv0LO3BYOJdjfc+j2hjv+mC9lF0 |
| UpWhCVJv3hHoFaxnz62GdROzf2wXz6aR9Saj1rYSvqT9jC20VInxqMufXNN2sbpo |
| Kyk6MTbAeepphQpfAWQv+ltWgBiEjuFxYdwv/vmw20996JV7O8nqkeCUW84B6su+ |
| Y3bbdP9o3DBtOT0j9LTB/FucmdNCNHoO+EnNBKJd6FoYTGLWi3Rq9DLx2V9tdJHo |
| Bn67dymcl+iyp337HJNY+qS+KCgoqAWlxkzXRiXKb/yluhXdIkqhg4kL8JPAJvfS |
| cs7Zn67Mx04ixJnRMYCDmxtD4xPsFMzM7g8m3PQp+nE7WhujM/ImM7kCDQRVyNYd |
| ARAAlw9H/1ybQs4K3XKA1joII16rta9KS7ew76+agXo0jeSRwMEQfItOxYvfhmo8 |
| +ydn5TWsTbifGU8L3+EBTMRRyzWhbaGO0Wizw7BTVJ7n5JW+ndPrcUpp/ilUk6AU |
| VxaO/8/R+9+VJZpoeoLHXYloFGNuX58GLIy1jSBvLsLl/Ki5IOrHvD1GK6TftOl5 |
| j8IPC1LSBrwGJO803x7wUdQP/tsKN/QPR8pnBntrEgrQFSI+Q3qrCvVMmXnBlYum |
| jfOBt8pKMgB9/ix+HWN8piQNQiJxD+XjEM6XwUmQqIR7y5GINKWgundCmtYIzVgY |
| 9p2Br6UPrTJi12LfKv5s2R6NnxFHv/ad29CpPTeLJRsSqFfqBL969BCpj/isXmQE |
| m4FtziZidARXo12KiGAnPF9otirNHp4+8hwNB3scf7cI53y8nZivO9cwI7BoClY6 |
| ZIabjDcJxjK+24emoz3mJ5SHpZpQLSb9o8GbLLfXOq+4uzEX2A30fhrtsQb/x0GM |
| 4v3EU1aP2mjuksyYbgldtY64tD35wqAA9mVl5Ux+g1HoUBvLw0h+lzwh370NJw// |
| ITvBQVUtDMB96rfIP4fL5pYl5pmRz+vsuJ0iXzm05qBgKfSqO7To9SWxQPdX89R4 |
| u0/XVAlw0Ak9Zceq3W96vseEUTR3aoZCMIPiwfcDaq60rWUAEQEAAYkCJQQYAQoA |
| DwUCVcjWHQIbDAUJB4YfgAAKCRA6RtGReVpYOEg/EADZcIYw4q1jAbDkDy3LQG07 |
| AR8QmLp/RDp72RKbCSIYyvyXEnmrhUg98lUG676qTH+Y7dlEX107dLhFuKEYyV8D |
| ZalrFQO/3WpLWdIAmWrj/wq14qii1rgmy96Nh3EqG3CS50HEMGkW1llRx2rgBvGl |
| pgoTcwOfT+h8s0HlZdIS/cv2wXqwPgMWr1PIk3as1fu1OH8n/BjeGQQnNJEaoBV7 |
| El2C/hz3oqf2uYQ1QvpU23F1NrstekxukO8o2Y/fqsgMJqAiNJApUCl/dNhK+W57 |
| iicjvPirUQk8MUVEHXKhWIzYxon6aEUTx+xyNMBpRJIZlJ61FxtnZhoPiAFtXVPb |
| +95BRJA9npidlVFjqz9QDK/4NSnJ3KaERR9tTDcvq4zqT22Z1Ai5gWQKqogTz5Mk |
| F+nZwVizW0yi33id9qDpAuApp8o6AiyH5Ql1Bo23bvqS2lMrXPIS/QmPPsA76CBs |
| lYjQwwz8abUD1pPdzyYtMKZUMwhicSFOHFDM4oQN16k2KJuntuih8BKVDCzIOq+E |
| KHyeh1BqWplUtFh1ckxZlXW9p9F7TsWjtfcKaY8hkX0Cr4uVjwAFIjLcAxk67ROe |
| huEb3Gt+lwJz6aNnZUU87ukMAxRVR2LL0btdxgc6z8spl66GXro/LUkXmAdyOEMV |
| UDrmjf9pr7o00hC7lCHFzw== |
| =WE0r |
| -----END PGP PUBLIC KEY BLOCK----- |
| |
| ``` |
| |
| ## Rationale |
| |
| ### Early Disclosure |
| |
| The Go security policy does not contain a provision for the early disclosure |
| of vulnerabilities to a small set of "trusted" partners. The Xen and WebKit |
| policies do contain provisions for this. According to several members of the |
| security response team at Google (Ben Laurie, Adam Langley), it is incredibly |
| difficult to retain secrecy of embargoed issues once they have been shared |
| with even a small number of partners. |
| |
| ### Security Review Team Membership |
| |
| The Go security policy does not contain formal provisions for nomination or |
| removal of members of the security review team. WebKit, for example, specifies |
| how new members can become members of the security review team. This may be |
| needed for the Go project at some point in the future; it does not seem |
| necessary at this time. |
| |
| ## Open issues |
| |
| * PGP key pair needed for security@golang.org address. |
| * Need to designate a primary and secondary alternative contact. |
| |