diff --git a/meetings/2024-09-04.md b/meetings/2024-09-04.md new file mode 100644 index 00000000..921857be --- /dev/null +++ b/meetings/2024-09-04.md @@ -0,0 +1,128 @@ +# Node.js Technical Steering Committee (TSC) Meeting 2024-09-04 + +## Links + +* **Recording**: +* **GitHub Issue**: + +## Present + +* Antoine du Hamel @aduh95 (voting member) +* Yagiz Nizipli @anonrig (voting member) +* Benjamin Gruenbaum @benjamingr (voting member) +* Ruben Bridgewater @BridgeAR (voting member) +* Gireesh Punathil @gireeshpunathil (voting member) +* Chengzhong Wu @legendecas (voting member) +* Marco Ippolito @marco-ippolito (voting member) +* Matteo Collina @mcollina (voting member) +* Michael Dawson @mhdawson (voting member) +* Richard Lau @richardlau (voting member) +* Ruy Adorno @ruyadorno (voting member) +* Paolo Insogna @ShogunPanda (voting member) +* Amir Montazery (Guest) +* Joe Sepi @ (Guest - Node.js CPC rep) + +## Agenda + +### Announcements +* Matteo, collaborator summit is confirmed for Dublin, if you are a collaborator planning on joining hope to see you there, it is two days after NodeConf. Nov 7-8th. +* Node 22.8.0 which fixed a regression with utf encoding and a few other bugs, If you are on Node.js 22.X you probably want to pick up. + +### Reminders + +* Remember to nominate people for the [contributor spotlight](https://github.com/nodejs/node/blob/main/doc/contributing/reconizing-contributors.md#bi-monthly-contributor-spotlight) + +### CPC and Board Meeting Updates + +* Joe + * Discussed discord server recently, basically in favor of the idea + * Code of conduct still a bit of a sticky point, have to figure out how to move forward with them + +*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/node + +* Fuzzing report + * needs to land and then we should be good to + publish report. + * Amir will then send updated report + * Michael will then send email to get final ok from the TSC. + +* deps: V8: backport f320600cd1f4 (V18.x CVE-2024-4761) #54597 + * Node.js 18 has an old version of V8, has quite a few CVEs reported against it because it is + part of chromium. + * These CVEs are outside the node.js threat model because they require untrusted code, + while the threat model indicates we trust the code that is asked to run. + * We had messaged that we would take some PRs to address to help people deal with the + scanning results. + * Some opposition, due to risk of accepting them. + * PR submitted did not build, highlighted risk + * Richard, even if it lands, does it even fix the problem with scanners reporting it. + * Has been pointed out that we have few people that can properly review V8 PRs which + adds to risk + * Matteo + * We should agree on approach/document + * Problem is that we are sending mixed signals + * Michael + * document that by default PRs would not be accepted if project does not + believe it affects ? + * Richard -> Node.js. Documentation for 18.x already limits changes to security fixes. + * Poala -> if it applies to our model should consider, but if not not a problem + * Richard -> a lot of V8 patches are not obvious if they are security related or not. Very hard + for us to understand if it will be low risk, and hard to see until we see the patch. + * Gireesh -> If we don’t accept this, what alternative exists for satisfying the scanners? + * Michael, nothing to satisfy the scanners, up to those who review the results to + allow/override. Richard they run off version numbers so even landing does not really help. + * Paolo -> how long would it take to write the patch + * Michael -> real challenge is how hard it will be to review, and be comfortable that it is + safe. + * Richard -> really hard until we see a PR to assess how easy/hard it will be. + * Richard have had some cases in the past that its been a big problem + * Possibly focus on messaging. + * Paolo, maybe we should just say we don’t do it. Due to risk of breakage. + * Richard, HeroDevs might be another option for people. + * Richard, existing release documentation already covers it. Please re-read and if not please + Disagree. I think -> , Issues which are + not applicable to Node.js critical bug fixes and security updates + +* Expose Undici's ProxyAgent and setGlobalDispatcher within Node [#43187](https://github.com/nodejs/node/issues/43187) + * Two parts + * For Node.js 23 do we want automatic support for HTTP_PROXY?, most frequent reason to + have access to undici from Node.js versus installing undici + * Problems exposing undici, cannot provide same stability guarantees + * Michael, can we expose HTTP_PROXY without exposing undici + * Marco, should we create a new namespace for undici + * Paolo, in favor as well, yes lets create a new namespace + * if we expose undici, then it would be experimental and we can break whenever. That would + be an approach. + * Marco, if requires new namespace, but at some point it would need to be as stable as the + other APIs + * Matteo, exposing has a lot of issues, keeping outside of core enabled a lot of + experimentation and speed. Barrier to entry is lower. But also less stable, some back and + forth + * Paolo, already have similar situation with llhttp, 3 release lines, if we choose to expose + undici can start to follow same approach. We would then have to start maintaining 3 different + versions of undici. + * Michael we are always in angst over thing that break, even if experimental so not really as + easy as we break at will, better to wait until rate of change drops + * Richard, llhttp is not quite the same as undici because we don’t expose it directly to users, + ie we can swap (and did swap) the implementation behind the scenes. + * Matteo has 3 parts + * the part we bundle in Node.js which is the Web standard part + * the part which is the public Undici API, quite large, has lots of agents, complex to address + lots of use cases. For example dispatchers, but they expose some very low level API. + * Generic question is people want to expose global dispatcher and access to dispatcher, + those have been relatively stable in API, minus the fact that we just changed the expose API. + +* doc: experimental flag for global accessible APIs [#54330](https://github.com/nodejs/node/pull/54330) + * Please take a look, on agenda for awareness + +## Strategic Initiatives + +* Skipped because we ran out of time. + +## Upcoming Meetings + +* **Node.js Project Calendar**: + +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.