doc: add minutes for Dec 2, 2016

meetings/2016-12-02/minutes.md

@@ -0,0 +1,125 @@
+# Node.js Security Working Group Meeting Dec 2, 2016
+
+* Date: 2016-12-02
+* Notes:
+  <https://docs.google.com/document/d/1-gY_sNt4CgySEale_13e2n9S9ucjuoM7djCq3Njal-0>
+* GH issue: N/A
+
+An informal meeting at the Node.js Interactive North America 2016 Collaborators
+summit, to discuss the formation of a Security Working Group.
+
+
+## Attendees
+
+* Bryan English @bengl
+* Devon Rifkin @drifkin
+* James Snell @jasnell
+* Matteo Collina @mcollina
+* Michael Alexander @mgalexander
+* Michael Dawson @mhdawson
+* Myles Borins @thealphanerd
+* Rod Vagg @rvagg
+* Sam Roberts @sam-roberts
+* William Kapke @williamkapke
+
+
+## Discussion
+
+Discussion was free form, notes follow.
+
+Role of Security WG:
+
+* Define what it means to bring NSP into the Foundation.
+* Define/refine process for security releases.
+  * Delegate actual triage of vulnerabilities to private group.
+* Single location with info about vulnerabilities in various versions of Node,
+  similar to CVE data.
+* Should security research and auditing be done proactively by Node?
+
+For example, HTTP has vulnerabilities because it’s loose with the protocol. Role
+of security group could be to set policies, such as whether we should make the
+HTTP implementation stricter.
+
+Purpose is *not* to respond to reports of security issues with Node.js, that is
+done by the "security team", see https://github.com/nodejs/node#security
+
+A problem has been that people expect that code is sandboxed in Node as in
+browser, but in fact it’s not. Part of work of Security WG could be to clarify
+that.
+
+Work Areas to be discussed in working group meetings, but topics raised
+included:
+
+- Is it worth looking at getting a sec eval of node?
+
+- What is security?
+  - Is there definitions that would help us? does CVE/CERT/?  have
+    classifications we can use?
+  - It would be helpful to have a stance on this so we can more clearly respond
+    to issues that are reported or claimed as "security issues", and we can
+    clarify what is a security problem. But err on the side of allowing more, as
+    sometimes other useful bugs come through.
+  - Could use existing classification systems, like “Data Disclosure”, “Remote
+    Code Execution”, etc.
+
+
+Ecosystem:
+
+- sec-wg could take some responsibility for fixing ecosystem issues
+- Need to also help module authors, for example we’ve filed CVE’s for npm
+  before.
+- Best practices on sec problems could use definition and
+  publication/evanglizing, so npmjs.org packages can follow a well-known and
+  robust procedure:
+  - What should an npm module author do if an issue is found in their module?
+  - How should they deal with it?
+  - Should there be a CVE?
+  - How should we (node/the node foundation/sec-wg) communicate with the
+    author?
+  - Its possible there should be a community vulnerability response list, that
+    is available if people want to report a vulnerability in community modules,
+    but don't know how, and do not want it in a public issue/PR on the modules
+    github repo.
+  - We could encourage package authors to include security contact info for
+    their packages.
+
+Create security guidelines and best practices for PR reviewers and module
+authors?
+
+Why machine readable security reports/info?  To enable an ecosystem on top of
+the data, such as `snyk` and `nsp`.
+
+
+Who might contribute to security research for Node?
+* Paid professional auditors
+* Existing security companies, e.g. Snyk, Lift, etc.
+* Universities and students
+
+
+If Node.js wants to support signed modules, would this be managed by the
+Security WG? CTC would ask for guidance from Security WG. Person who prepares PR
+could collaborate with Security WG at start. Partly depends on earned trust of
+Security WG.
+
+Recommendations to the CTC and others on security-related proposals would
+ideally be part of this group’s role.
+
+OpenSSL is a significant source of issues, and Linux Foundation is working to
+address. Would be ideal to involve Linux Foundation Core Infrastructure
+Initiative (CII), which is responsible for core Internet components like
+OpenSSL.
+
+
+Several teams with different responsibilities:
+
+* Security Response for Core
+* Security Response for Ecosystem
+* Security Policy
+
+Ultimately it’s the CTC’s responsibility for executing/implementing policy, so
+Response team for Core should report to CTC.
+
+Should ecosystem response team be different? Would then be under management of
+TSC.
+
+Work closely with Linux Foundation Core Infrastructure Initiative.