Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node.js Foundation Technical Steering Committee (TSC) Meeting 2018-12-05 #637

Closed
mhdawson opened this issue Dec 3, 2018 · 7 comments
Closed
Assignees

Comments

@mhdawson
Copy link
Member

mhdawson commented Dec 3, 2018

Time

UTC Wed 05-Dec-2018 12:00 (12:00 PM):

Timezone Date/Time
US / Pacific Wed 05-Dec-2018 04:00 (04:00 AM)
US / Mountain Wed 05-Dec-2018 05:00 (05:00 AM)
US / Central Wed 05-Dec-2018 06:00 (06:00 AM)
US / Eastern Wed 05-Dec-2018 07:00 (07:00 AM)
London Wed 05-Dec-2018 12:00 (12:00 PM)
Amsterdam Wed 05-Dec-2018 13:00 (01:00 PM)
Moscow Wed 05-Dec-2018 15:00 (03:00 PM)
Chennai Wed 05-Dec-2018 17:30 (05:30 PM)
Hangzhou Wed 05-Dec-2018 20:00 (08:00 PM)
Tokyo Wed 05-Dec-2018 21:00 (09:00 PM)
Sydney Wed 05-Dec-2018 23:00 (11:00 PM)

Or in your local time:

Links

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

  • HTTP/1 request destroy behavior change on framing error #24586
  • Fixing child_process module to check values passed strictly to the options object #24267

nodejs/TSC

  • Tracking issue for updating TSC on Board Meetings #476
  • Strategic Initiatives - Tracking Issue #423

nodejs/community-committee

  • Travel Fund Updates #426
  • Node Store Launch #425

Invited

Observers/Guests

Notes

The agenda comes from issues labelled with tsc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

Zoom link: https://zoom.us/j/611357642
Regular password

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.

Many of us will be on IRC in #node-dev on Freenode if you'd like to interact, we have a Q/A session scheduled at the end of the meeting if you'd like us to discuss anything in particular. @nodejs/collaborators in particular if there's anything you need from the TSC that's not worth putting on as a separate agenda item, this is a good place for that.


Invitees

Please use the following emoji reactions in this post to indicate your
availability.

  • 👍 - Attending
  • 👎 - Not attending
  • 😕 - Not sure yet
@mhdawson mhdawson self-assigned this Dec 3, 2018
@rvagg
Copy link
Member

rvagg commented Dec 3, 2018

Probably won't be attending, too late in the day.

Re "Fixing child_process module to check values passed strictly to the options object nodejs/node#24267", I'm responsible for that being on the agenda. I'm not an explicit -1 but I'm very dubious and would like the TSC to make an intentional decision about this one. Either way it's going to set a precedent.

The argument here is that it's a security concern that we don't check for own properties on the options argument in child_process, so the semver-major change is to enforce that so you can accidentally have inherited properties impacting your child_process calls.

I'm all for this philosophically and I wish our entire API was super strict and explicit, but it's not, it's quite relaxed. So, if we accept that there is a security concern with child_process, why not vm? Then why not fs since you can get pretty creative with that? and net? ... and every part of our API. You could make the same argument for many of the things Node exposes and they differ only in degree and even that's a subjective measure.

I've probed in the issue thread but nobody who's accepting this change seems to have a limiting principle. If we don't have such a principle then what will you say to the PRs that come to the rest of our API? As I said above, I don't think "security" is good enough because that argument is potentially expansive. The conclusion of this is: are you prepared for an ongoing series of major breaking changes to our entire API surface with this same theme?

Of course the alternative is roughly the status quo: Node is not a sandbox, sanitise your inputs, don't let user-data get deep into your application without heavy filtering, etc. If you are letting user input get near your options objects then you're doing it wrong and Node can't be held responsible because you treat it like a browser. Or something like that.

@mcollina
Copy link
Member

mcollina commented Dec 3, 2018

I'd like to keep nodejs/node#24586 in the agenda because it's something we need to talk about/awareness. The actual situation is resolved.

Re "Fixing child_process module to check values passed strictly to the options object nodejs/node#24267", I'm responsible for that being on the agenda. I'm not an explicit -1 but I'm very dubious and would like the TSC to make an intentional decision about this one. Either way it's going to set a precedent.

@rvagg I'd add a -1 from myself to block until a full @nodejs/tsc discussion.

@mcollina mcollina assigned mcollina and unassigned mhdawson Dec 3, 2018
@mcollina
Copy link
Member

mcollina commented Dec 3, 2018

I'll be chairing this meeting.

@gabrielschulhof
Copy link

... and too early in the day for me 😕

Re nodejs/node#24267 the change should perhaps not go in. Object.prototype and an own property are not the only two places where a value can be stored. There may be a legitimate prototype chain such that there is a prototype in between Object.prototype and the object itself. IOW a property on the options object may legitimately not be an own property. With this change we'd be expressing an opinion that doesn't really give us any more security because of all the other changes we'd have to make, like also addressing nodejs/node#24267 (comment).

@MylesBorins
Copy link
Member

can't make it... too early, apologies

re: nodejs/node#24586 I think the big question is if want to rush to get it into v10.14.2

I don't have an opinion on nodejs/node#24267

re: #476 we have a board meeting next Thursday. I've asked for us to approve the charter change in #627.

I'm also working with foundation folks to secure a venue for JSConf EU Collaborator Summit. Also trying to get details regarding location and timing for next years Node+JS Interactive.

LMK if there is anything else board related I can help with.

@mcollina
Copy link
Member

mcollina commented Dec 5, 2018

Also trying to get details regarding location and timing for next years Node+JS Interactive.

@MylesBorins the next NodeConf.eu will be held 10th - 13th November 2019. Can you ensure we won't conflict with Interactive?

mcollina added a commit that referenced this issue Dec 5, 2018
@thefourtheye
Copy link
Contributor

Moderation team updates:

  1. Blocked a user for spamming - https://github.com/nodejs/moderation/issues/254

@nodejs/tsc @nodejs/community-committee @nodejs/moderation

mcollina added a commit that referenced this issue Dec 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants