-
Notifications
You must be signed in to change notification settings - Fork 134
/
Copy path2024-09-04.md
128 lines (107 loc) · 6.69 KB
/
2024-09-04.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
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 @<[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
* 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 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.