-
Notifications
You must be signed in to change notification settings - Fork 133
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 9 Sep 2024 (#1613)
* doc: add minutes for meeting 9 Sep 2024 Signed-off-by: Michael Dawson <midawson@redhat.com>
- Loading branch information
Showing
1 changed file
with
128 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,128 @@ | ||
| # 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 @<sepi@joesepi.com> (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 | ||
|
|
||
| * 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 | ||
| * <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 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**: <https://nodejs.org/calendar> | ||
|
|
||
| Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. |