From 37dbec029ced407c4798e7b12e628e96bbb218e5 Mon Sep 17 00:00:00 2001 From: Sam Roberts Date: Mon, 22 Apr 2019 11:01:25 -0700 Subject: [PATCH] doc: add minutes for April 20, 2019 --- meetings/2019-04-22.md | 110 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 110 insertions(+) create mode 100644 meetings/2019-04-22.md diff --git a/meetings/2019-04-22.md b/meetings/2019-04-22.md new file mode 100644 index 000000000..b242af699 --- /dev/null +++ b/meetings/2019-04-22.md @@ -0,0 +1,110 @@ +# 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.