forked from nodejs/TSC
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc: add minutes for meeting 8 Dec 2021 (nodejs#1137)
* doc: add minutes for meeting 8 Dec 2021 * Update meetings/2021-12-08.md Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com> Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
- Loading branch information
Showing
1 changed file
with
123 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,123 @@ | ||
| # Node.js Technical Steering Committee (TSC) Meeting 2021-12-08 | ||
|
|
||
| ## Links | ||
|
|
||
| * **Recording**: <https://www.youtube.com/watch?v=CTHxaSwEH1g> | ||
| * **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1136> | ||
|
|
||
| ## Present | ||
|
|
||
| * Antoine du Hamel @aduh95 (TSC) | ||
| * Beth Griggs @BethGriggs (TSC) | ||
| * Ruben Bridgewater @BridgeAR (TSC) | ||
| * Colin Ihrig @cjihrig (TSC) | ||
| * Gireesh Punathil @gireeshpunathil (TSC) | ||
| * Richard Lau @richardlau (TSC) | ||
| * Robert Nagy @ronag (TSC) | ||
| * Tobias Nießen @tniessen (TSC) | ||
| * Rich Trott @Trott (TSC) | ||
|
|
||
| ## Agenda | ||
|
|
||
| ### Announcements | ||
|
|
||
| * @bnb has been onboarded as a collaborator | ||
|
|
||
| ### CPC and Board Meeting Updates | ||
|
|
||
| No updates. | ||
|
|
||
| \*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting. | ||
|
|
||
| ### nodejs/node | ||
|
|
||
| * stream: remove thenable support [#40773](https://github.com/nodejs/node/pull/40773) | ||
| * ronag: Discussed last meeting. We’re OK bypassing the usual deprecation procedure. tsc-agenda label has been removed. Nothing to discuss today. | ||
|
|
||
| * docs: Clarification around real world risks and use cases of VM module [#40718](https://github.com/nodejs/node/issues/40718) | ||
| * trott: Defer to future meeting, maybe when mcollina is here. Not time-sensitive, but is important. | ||
|
|
||
| * Rename default branch from "master" to "main" [#33864](https://github.com/nodejs/node/issues/33864) | ||
| * gireeshpunathil: mhdawson has been the champion on this. Still some work to do. (2 repos pending for migration: core and build.) Leave until it gets done, basically. | ||
|
|
||
| * Migration of core modules to primordials [#30697](https://github.com/nodejs/node/issues/30697) | ||
| * gireeshpunathil: Next action, according to minutes from last meeting, was to agree on a set of voting options, but BrigeAR has concerns about the set of options. I don’t think we should go back to the wider collaborator base at this point. | ||
| * ronag: Last time I was here, we had three options that were proposed but the concern was that the options were too ambiguous. | ||
| * BridgeAR: I don’t know about the three-options TSC meeting thing, but last week, we spoke about goals and approaches. In this case, we would have multiple iterations of voting. We would have to agree on goals, and which goals might possibly reach that goal. That makes the voting process difficult. I suggest that we have clear suggestions that outline both of those things. I asked all TSC members to mention their opinions about what options would be good or not. Feedback has been little-to-none since then. | ||
| * gireeshpunathil: TSC had this come to them. TSC was unable to make a decision. So as to make a decision possible, we began discussions with people from the project who have opinions and then we came back to the TSC with 3 options. So are we circling back again and looking for TSC to do that work again? | ||
| * aduh95: I can try to write my thoughts more clearer if people want, but I think I’ve said everything I have to say. | ||
| * gireeshpunathil: One approach might be to bring the SMEs to speak to the TSC. I believe we have tried that option. | ||
| * BridgeAr: My suggestions were concrete and I had hoped that it lower the ambiguity in general. I had a list of nine different points. I’m not certain if we have to limit it below that. If anyone believes there is an option that is bad or good, let’s say it. Maybe do it right now? | ||
| * ronag: I agree with Ruben’s approach. | ||
| * gireeshpunathil: There is no best option, so one problem is that we don’t have agreement on prioritizing performance or robustness. | ||
| * ronag: There are really four possible goals. Tamper-free entire process. I don’t see how that’s possible. Tamper-free when module loading. That’s possible. Tamper-free when it doesn’t affect performance. I don’t see how that’s possible. It takes so much time to test and troubleshoot. And then we have a fourth option that I’m not even sure what it is. | ||
| * BridgeAR: Following on ronag’s words, we can define the options right now. | ||
| * ronag: I’m happy to go through the options. Ruben and Antoine are the primary folks on the opposite ends of the issue in the TSC. We have them both. So we can do it. | ||
| * BridgeAR: targos and mcollina were involved and aren’t here. But I think we can do this. | ||
|
|
||
| *** | ||
|
|
||
| Primordials options: | ||
|
|
||
| 1. Module loading and policy would be tamper-proof. We would have to define module loader dependencies. Some dependencies are pulled in for things that might not be necessary for module loaders to work. | ||
| 2. Fully migrate module loaders and policy code to C++ and undo all primordials. No ambiguity about what code has to be migrated and what could does not. | ||
| 3. Migrate all modules to primordials. (Probably not feasible, in Ruben’s opinion.) | ||
| 4. Migrate all code to C++. | ||
| 5. Undo all primordials. | ||
| 6. ~~Ask community in similar fashion as we did with unhandled rejections.~~ Ask community for feedback on performance vs. robustness vs. core maintainability/developer experience. | ||
| 7. Move REPL code execution to child process to keep REPL working even if runtime would crash from tampering. | ||
| 8. Do 1 or 2 in addition to 7. | ||
| 9. Do not port any further code to primordials but do not remove existing primordials either. | ||
| 10. (from Antoine) Use [stage 1 TC39 proposal-bind-this](https://github.com/tc39/proposal-bind-this) for <https://github.com/nodejs/node/issues/30697> | ||
|
|
||
| * ronag: 1 and 2 are valuable options if the people working on module loaders are interested in putting in that effort. | ||
| * aduh95: Yes, moving to the C++ layer or using primordials depends on who is putting in the work. | ||
| * ronag: Merge 1 and 2 into a single option? | ||
| * aduh95: Maybe the clear path forward is to agree on tests that should pass. | ||
| * tniessen: Every time we change code anywhere, we have to check if it is a dependency of the module loader. Then if we change the module implementation, we’ll have to check for new dependencies that are introduced. And now it might not be clear why, for example, crypto module uses primordials. | ||
| * aduh95: I second that. That’s why I think tests would be the better choice than a list. | ||
| * tniessen: Tests will only tell us if we test every possible thing that can be modified by users. | ||
| * ronag: Maybe we can restrict the dependencies? | ||
| * tniessen: Or just move to C++. | ||
| * ronag: I guess we can leave that up to the implementing developer. | ||
| * BridgeAR: I agree with tniessen that maintaining the list would be onerous. | ||
| * aduh95: I’m not sure about that. I’ve written code that tries to change all the builtins and injected and it was giving me the list of all the non-primordials that were affected. Maybe it is possible. | ||
| * ronag: Let’s continue down the list as these are viable options. | ||
| * Agreement that option 3 is not viable at this time. | ||
| * Option 4 is not viable. | ||
| * ronag: There are people that want that. I’m not sure if it is a politically viable choice. | ||
| * richardlau: We can’t do option 5 because we don’t have options. | ||
| * tniessen: Agreed. People will want tamper-proof but this is about trade offs. | ||
| * ronag: Right, it’s robustness vs performance vs. developer experience. What we value the most will guide the decision. If we value developer experience above all else, for example, we won’t want primordials. On the other hand, robustness points to primordials. Maybe the community can help us weigh those things, rather than primordials. On the other hand, we kind of have that in the technical priorities list. | ||
| * gireeshpunathil: Yeah, primordials may be hard for the community to answer, but robustness vs. performance is something they can weigh in on. And we can do that as an activity in a broader activity. | ||
| * BridgeAR: Let’s reword 6 to make it viable. | ||
| * BridgeAR: On 7, I searched for issues about tampering and they seemed to be about REPL mostly. So we could mitigate that way. | ||
| * aduh95: I don’t think option 7 should be part of the vote. It doesn’t have to do with what we’re discussing here. Someone can do it or not. But it doesn’t address the issue at hand. | ||
| * cjihrig: +1 to dropping option 7 | ||
| * BridgeAR: Removing it and number 8. | ||
|
|
||
| ### nodejs/TSC | ||
|
|
||
| * Invite TSC members in the Google Calendar event for meetings [#1133](https://github.com/nodejs/TSC/issues/1133) | ||
| * Ran out of time. Deferred to next week. | ||
| * Update TSC meeting times [#1132](https://github.com/nodejs/TSC/issues/1132) | ||
| * Ran out of time. Deferred to next week. | ||
| * add security triaging to core repo GOVERNANCE.md and/or charter? [#1100](https://github.com/nodejs/TSC/issues/1100) | ||
| * Ran out of time. Deferred to next week. | ||
|
|
||
| ### nodejs/admin | ||
|
|
||
| * move bnb/devenv to nodejs/devcontainer [#641](https://github.com/nodejs/admin/issues/641) | ||
| * Ran out of time. Deferred to next week. | ||
|
|
||
| ## Strategic Initiatives | ||
|
|
||
| * V8 currency: | ||
| * V8 9.6 landed in Node.js 17.2.0 | ||
| * V8 9.7 is blocked on a V8 bug: <https://bugs.chromium.org/p/v8/issues/detail?id=12421> | ||
|
|
||
| ## Upcoming Meetings | ||
|
|
||
| * **Node.js Foundation Calendar**: <https://nodejs.org/calendar> | ||
|
|
||
| Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. |