doc: add minutes for meeting 9 Sep 2024

meetings/2024-09-04.md

@@ -0,0 +1,124 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2024-09-04
+
+## Links
+
+* **Recording**:  <https://www.youtube.com/watch?v=lgexs1iE7AE>
+* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1612>
+
+## 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 @<[email protected]> (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. <https://github.com/openjs-foundation/summit/issues/419>
+* 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
+
+*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting.
+
+### nodejs/node
+
+* Fuzzing report
+  * <https://github.com/nodejs/uvwasi/pull/280> 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 -> <https://github.com/nodejs/release#release-phases>, 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 guarrantees
+    * 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**: <https://nodejs.org/calendar>
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.