Skip to content

Commit

Permalink
doc: add minutes for April 20, 2019
Browse files Browse the repository at this point in the history
  • Loading branch information
sam-github committed Apr 22, 2019
1 parent 524c2ad commit 37dbec0
Showing 1 changed file with 110 additions and 0 deletions.
110 changes: 110 additions & 0 deletions meetings/2019-04-22.md
Original file line number Diff line number Diff line change
@@ -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.

0 comments on commit 37dbec0

Please sign in to comment.