doc: add minutes for April 20, 2019

PR-URL: nodejs/security-wg#523
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

meetings/2019-04-22.md

@@ -0,0 +1,109 @@
+# Node.js Foundation Security WorkGroup Meeting 2019-04-22
+
+## Links
+
+* **Recording**: https://www.youtube.com/watch?v=9sYq2gfooro
+* **GitHub Issue**: https://github.com/nodejs/security-wg/issues/519
+
+## Present
+
+* Sam Roberts (@sam-github)
+* Michael Dawson (@mhdawson)
+* Reed Loden (@reedloden)
+* Tierney Cyren (@bnb)
+
+## Agenda
+
+## Announcements
+
+*Extracted from **security-wg-agenda** labelled issues and pull requests from
+the **nodejs org** prior to the meeting.
+
+### nodejs/TSC
+
+* Regular schedule for Security releases? [#647](https://github.com/nodejs/TSC/issues/647)
+  * Tierney, affects high severity ones? Michael no, those still go out adhoc as
+    they need to go out quickly.
+  * For low severity vulns, might be fewer but should be less work.
+  * Planned releases would hopefully let people working on the vulns more time
+    to plan in advance of a security release
+  * Security releases have occasionally bumped ongoing non-security releases,
+    disturbing their schedule. By planning, we can slot them in between planned
+    LTS releases, so there is less conflict.
+  * Tierney suggested adding a ‘security’ tag in the release meta-data (similar
+    to how there is currently an ‘lts:’ tag). Sam: suggested this be opened as
+    an issue in nodejs/release, because its an obviously sensible thing to do.
+  * Ask the release team for a couple 2019 candidate dates that work well into
+    their plans. Do this within the existing issue.
+  * Adjust the HackerOne “time to resolution” to 4 months.
+
+### nodejs/security-wg
+
+#### HackerOne's managed services [#516](https://github.com/nodejs/security-wg/issues/516)
+  * Ford Foundation has provided some dollars for:
+    * provide technical program manager
+    * triage team will take incoming reports and validate as best they can
+    * handling pre-determined bounties
+  * should cover low hanging fruit in terms of getting report into a state where
+    it is easier to review/make decision on report.
+  * Sam: one concern was about issues being closed without somebody from Node.js
+    community, but great to have initial triage by people with broader security
+    perspective.
+  * Reed: Agreement on the core side, seems like positive for ecosystem as well. 
+  * No objections from those in meeting.
+  * Sam: in favour
+  * Michael: in favour
+  * Reed: Vladimir was in favour
+  * Sam: Liran should give approval.
+  * Some discussion of CVE allocation. We (Sam) should send Mitre an email
+    saying we are going to be trying allocating CVEs through HackerOne, and if
+    it goes well, we won’t need to be a CNA in 2020.
+
+#### Reaching out to other projects of the OpenJS Foundation [#511](https://github.com/nodejs/security-wg/issues/511)
+  * Michael: suggests waiting for the CPC to form (another month), then using
+    them to do the reach-out.
+
+#### Attendance in the upcoming Collaborator Summit in May? [#510](https://github.com/nodejs/security-wg/issues/510)
+  * Michael, Tierney, and Sam will be at summit
+  * Liran, will you put together some slides? One of us can present them.
+  * If no one who is working on node “sec” APIs related to module sandboxing
+    (Bradley, Anna) can do it, Sam might be able to put together some slides on
+    that.
+
+#### Large-scale disclosure guidelines [#505](https://github.com/nodejs/security-wg/issues/505)
+  * Don’t have Liran or Vladimir so defer to next time.
+  * https://github.com/nodejs/node/pull/27298 - sec-wg should weigh in if they
+    have opinions.
+  * Michael points out another soft way would be to have a “opt-in to removing
+    it” option, but Reed suggested that people who care enough about security to
+    know they can run in more secure mode _also_ care enough that they have
+    already taken care of the problem.
+  * Sam: there is another intermediate step, keep the current deprecation, but
+    remove the single line that disables the deprecation if the usage is in a
+    sub-dependency. I may open another PR that just removes that line, so more
+    consumers of modules may see deprecations, and put pressure on the packages
+    they use
+  * Tierney: offers to go through some of the packages using the insecure Buffer
+    and PR fixes.
+  * Chalker has proposed moving his research repo into the public, which could
+    be a reason for another blog post, which might cause people to find any of
+    their sub-deps that have Buffer issues, and PR fixes (or report issues).
+  * Sam: will confirm whether there is a env var or other way of enabling the
+    Buffer deprecation for sub-deps at run-time, so people can run their own
+    tests and see if their sub-deps have the insecure usage
+
+#### should there be security-wg presentation at nodeconf.eu? [#504](https://github.com/nodejs/security-wg/issues/504)
+  * Sam: not discussed, not enough people at meeting, leave for next.
+
+#### \[ANN - APR 26th 2019\] Migrating vulnerabilities database into its own repository [#494](https://github.com/nodejs/security-wg/issues/494)
+ * Michael: on agenda so that any observers can understand that we are moving
+   the DB, and if they are consuming it they should pay attention to the
+   announcement
+
+## Q&A, Other
+
+## Upcoming Meetings
+
+* **Node.js Foundation Calendar**: https://nodejs.org/calendar
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.