Security Collab Space Meeting - September 29, 2025

Security Collab Space Meeting - September 29, 2025 🔗 **Source:** [Security Collab Space Meeting - September 29, 2025](https://www.youtube.com/watch?v=PsYTTXuKvuU) > [!note]+ Document Notes > tags: [nodejs, npm-security, supply-chain, publishing-security] > author: OpenJS Foundation Security Collab Space > source: YouTube > reference: https://www.youtube.com/watch?v=PsYTTXuKvuU > date created: 2024-12-19 14:30 > > # 🏷️ Title: Security Collab Space Meeting - September 29, 2025 >  ## 🧰 Action Inbox - [H1] Review npm publishing guidance draft for main track talk — feedback needed before Node Collab Summit #security - [H2] Create DM group for expanded collab summit session planning — include James and interested parties #collaboration - [H3] Stack rank feature requests for GitHub/npm teams — prioritized ask list from collaborators #strategy ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [OpenJS Foundation](https://openjsf.org/) - [npm Security Best Practices](https://docs.npmjs.com/security) ## 📝 Summary - OpenJS Security Collab Space discusses npm publishing security guidance and Node.js collab summit session planning - Focus on creating practical recommendations for maintainers while addressing enterprise needs - Current trusted publishing deemed inadequate for solo maintainers due to lack of two-factor authentication - Session will produce prioritized feature requests for GitHub and npm teams - Discussion reveals significant gaps in current security workflows and tooling ## 📖 Main Content The meeting centers on developing comprehensive guidance for secure npm publishing practices. Wes is preparing both a main track talk and a Node.js collab summit session, with the latter focused on generating concrete asks for the GitHub and npm teams. The discussion reveals that current "trusted publishing" features are inadequate, particularly for solo maintainers, as they lack proper two-factor authentication support. Key security recommendations emerging include local publishing workflows with ephemeral tokens, granular access controls, and resistance to account takeover attacks. Enterprise users face additional challenges with token rotation requirements and automation needs that current tooling doesn't adequately support. The conversation expands to broader supply chain security topics, including Node.js permission models and their limitations in preventing sophisticated attacks that use process spawning to escape sandboxes. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/PsYTTXuKvuU?t=0) — [H1] npm Publishing Security Guidance Introduction - Key idea: Creating non-complicated guidance for complex npm publishing security - Evidence: "creating some guidance and trying to make it not complicated even though we think it will be complicated no matter what" #### ⏱️ [02:15](https://youtu.be/PsYTTXuKvuU?t=135) — [H2] Two-Part Approach: Main Track and Collab Summit - Key idea: Main track focuses on four reasonable setups with pros/cons analysis - Evidence: "four reasonable setups with pros and cons and really trying to focus for those folks on how to think about this problem" #### ⏱️ [04:30](https://youtu.be/PsYTTXuKvuU?t=270) — [H3] Enterprise vs Individual Publisher Requirements - Key idea: Corporate environments need different, stronger security recommendations - Evidence: "Are they the same recommendations for an enterprise or a corporation to follow, or are there different stronger recommendations" #### ⏱️ [08:45](https://youtu.be/PsYTTXuKvuU?t=525) — [H1] Token Management Challenges for Organizations - Key idea: Seven-day token rotation creates operational nightmares for large teams - Evidence: "this whole thing of them cycling those every seven days is a nightmare. Like we can't do it right" #### ⏱️ [12:00](https://youtu.be/PsYTTXuKvuU?t=720) — [H2] Trusted Publishing Inadequacy for Solo Maintainers - Key idea: Current trusted publishing lacks two-factor authentication support - Evidence: "there is not a single scenario today that is acceptable with trusted publishing... especially for a solo maintainer" #### ⏱️ [15:30](https://youtu.be/PsYTTXuKvuU?t=930) — [H3] Account Takeover Vulnerability in Multi-Maintainer Setups - Key idea: Protected environments can be bypassed through account compromise - Evidence: "if one of the accounts are taken over fully taken over... they can add a new user and it can be anybody" #### ⏱️ [18:45](https://youtu.be/PsYTTXuKvuU?t=1125) — [H2] Staged Publishing Alternative Workflow - Key idea: Publish to non-latest tags first, then promote with two-factor auth - Evidence: "publish to a next disc tag... you would have a secondary workflow for the promote" #### ⏱️ [22:00](https://youtu.be/PsYTTXuKvuU?t=1320) — [H3] One-Way Settings Operational Concerns - Key idea: Irreversible security settings require fine-grained permissions or support workflows - Evidence: "you can't even onboard publishers unless you've gone through and made sure they are like really experienced" #### ⏱️ [26:15](https://youtu.be/PsYTTXuKvuU?t=1575) — [H1] Most Secure Local Publishing Workflow - Key idea: Physical machine token storage provides strongest security for solo maintainers - Evidence: "the most secure approach is local publish with a token that only lives on a physical machine" #### ⏱️ [29:30](https://youtu.be/PsYTTXuKvuU?t=1770) — [H2] Ephemeral Token Workflow Recommendation - Key idea: Login, publish, logout workflow with token deletion for security - Evidence: "npm log in npm publish npm log out... that token is ephemeral" #### ⏱️ [33:45](https://youtu.be/PsYTTXuKvuU?t=2025) — [H3] CI Publishing with Third-Party Integration - Key idea: Granular tokens with external OTP handling can work for some scenarios - Evidence: "I use a granular publish token... but it relies on a third party server" #### ⏱️ [38:00](https://youtu.be/PsYTTXuKvuU?t=2280) — [H2] Permission Model Limitations Against Sophisticated Attacks - Key idea: Node.js permission model can be bypassed through process spawning - Evidence: "they used node as the entry point... they exec, you know, the the claw to basically say unsafeely run all these commands" #### ⏱️ [42:15](https://youtu.be/PsYTTXuKvuU?t=2535) — [H3] eBPF Kernel-Level Sandboxing Research - Key idea: Kernel-level restrictions could provide more effective sandboxing than file path permissions - Evidence: "once you start to restrict that by the kernel using ebpf you can be way more you can definitely create a sandbox" #### ⏱️ [45:30](https://youtu.be/PsYTTXuKvuU?t=2730) — [H1] Extended Collab Summit Session Planning - Key idea: Expanding session scope to cover both npm publishing and Node.js security - Evidence: "extend your proposal a bit... from 30 minutes to 1 hour and then we start from npm and then we jump to no.js" ## 📚 References - [npm Documentation](https://docs.npmjs.com/) - [Node.js Security Working Group](https://github.com/nodejs/security-wg) - [OpenJS Foundation Security Collab Space](https://github.com/openjs-foundation/security-collab-space) ## 🗣️ Paraphrase - Current npm publishing security requires complex manual workflows to achieve adequate protection - Trusted publishing features are incomplete and inadequate for most use cases, especially solo maintainers - Enterprise organizations face significant operational challenges with current token management requirements - Node.js permission model has fundamental limitations that sophisticated attacks can bypass - The security community needs to provide prioritized, actionable feedback to platform maintainers ## 📰 Newsletter **Securing Your npm Publishing Workflow: Key Insights from OpenJS Security Collab** The OpenJS Security Collab Space recently discussed critical gaps in npm publishing security and practical recommendations for maintainers. Key takeaway: current "trusted publishing" features lack adequate two-factor authentication support, making them unsuitable for most scenarios. **Practical Benefits:** - Clear guidance on secure local publishing workflows - Understanding of enterprise-specific security challenges - Roadmap for platform improvements needed from GitHub/npm **Essential Security Workflow:** 1. Use ephemeral tokens (npm login → publish → logout) 2. Implement granular access controls where possible 3. Plan for account takeover scenarios, not just automated attacks The discussion highlights the need for better tooling around staged publishing, one-way security settings, and kernel-level sandboxing approaches for comprehensive supply chain security. Resources: [OpenJS Security Collab](https://github.com/openjs-foundation/security-collab-space), [npm Security Best Practices](https://docs.npmjs.com/security), [Node.js Security Working Group](https://github.com/nodejs/security-wg) ## ✅ Action Items #### DevRel - Developer education: Security workshop curriculum for npm publishing best practices - Developer experience: Document security workflow pain points and API gaps - Community engagement: Facilitate feedback collection from enterprise users on token management #### OSPO - Security Management: Vulnerability assessment of current npm publishing workflows - Policy & Governance: Establish secure publishing guidelines for organizational packages - Developer Support: Training materials for secure token lifecycle management #### Community - Maintainers: Security assessment templates for solo vs multi-maintainer projects - Contributors: Onboarding materials covering secure development practices - Ecosystem: Cross-project coordination on security tooling standards #### WordPress - Security: Audit WordPress package publishing workflows against npm security recommendations - Documentation: Update publishing guidelines to reflect current security best practices ## 🧪 Hypotheses - Local publishing with ephemeral tokens provides better security than CI-based publishing for solo maintainers - Current trusted publishing adoption is low due to inadequate two-factor authentication support - Enterprise token rotation requirements create security gaps rather than improvements - Kernel-level sandboxing (eBPF) would be more effective than application-level permission models ### 📊 Methodology - Comparative security analysis of publishing workflows under different attack scenarios - Survey enterprise users about current token management pain points and workflows - Threat modeling analysis comparing account takeover vs automated attack resistance ### ❓ Questions - How can npm implement granular, time-limited token creation APIs for better automation? - What would adoption look like for kernel-level sandboxing solutions in the Node.js ecosystem? - How should the community prioritize security improvements versus usability concerns? ### 🔮 Future Research - eBPF-based sandboxing integration with Node.js runtime and package management - API design for automated, secure token lifecycle management - Cross-platform security workflow standardization across package managers ### 💡 Implications - Practice: Organizations need to reassess current npm publishing workflows and token management practices - Policy: Platform providers need clearer prioritization of security features versus convenience - Security: Current security models have fundamental limitations requiring architectural changes - Education: Security guidance must account for operational complexity in real-world deployments ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12-14 (technical discussion) #### 👀 Visual learners - Present: None identified in audio-only meeting - Improve: Security workflow diagrams, threat model visualizations, comparison charts #### 🔊 Aural learners - Present: Full meeting recording with technical discussion - Improve: Edited highlights reel with key security recommendations #### 🗣️ Verbal learners - Present: Detailed explanations of security concepts and trade-offs - Improve: Glossary of technical terms, analogies for complex security concepts #### 🧩 Kinesthetic learners - Present: None in discussion format - Improve: Hands-on workshops, token management labs, security audit checklists #### 🧠 Logical learners - Present: Risk assessment frameworks, comparative security analysis - Improve: Decision trees for security choices, threat modeling templates #### 🧑‍🤝‍🧑 Social learners - Present: Collaborative discussion format, community feedback integration - Improve: Security review partnerships, group threat modeling sessions #### 🧘‍♀️ Solitary learners - Present: Individual assessment of security practices - Improve: Self-assessment security checklists, personal workflow templates #### 🌿 Naturalistic learners - Present: Ecosystem thinking about security interdependencies - Improve: Supply chain mapping exercises, ecosystem impact analysis ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Audio content available, technical discussion well-structured - Improve: Transcript with proper heading structure, technical term definitions #### Keyboard navigation - Present: Standard video player controls - Improve: Timestamped navigation, searchable transcript interface #### Contrast and readability - Present: Audio-only content avoids visual contrast issues - Improve: High-contrast transcript formatting, clear visual hierarchy #### Text resizing and reflow - Present: Not applicable for audio content - Improve: Responsive transcript layout supporting zoom to 200% #### Media and captions - Present: Audio available but no captions provided - Improve: Professional captions with technical term accuracy, downloadable transcript #### Forms and interactions - Present: Simple video controls only - Improve: Interactive transcript with timestamp jumping, note-taking features ### 🌍 DEIB Assessment #### Cultural breadth - Present: English-only discussion, primarily North American perspectives - Improve: Multi-regional security practice examples, internationalization considerations #### Inclusive language - Present: Technical jargon defined in context, professional tone - Improve: Plain language security summaries, avoid assumptions about organizational resources #### Neurodiversity support - Present: Structured agenda, clear topic transitions - Improve: Content warnings for complex technical discussions, processing time accommodation #### Representation - Present: Male-dominated technical discussion typical of security spaces - Improve: Diverse speaker representation, accessibility of participation #### Psychological safety - Present: Respectful technical debate, acknowledgment of different perspectives - Improve: Explicit inclusion of different organizational contexts and constraints ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Security workflow analysis follows clear threat modeling principles - Inductive strength: Conclusions drawn from specific attack patterns and platform limitations - Causal reasoning: Clear connection between security measures and attack prevention - Analogical strength: Enterprise vs individual security needs appropriately compared #### Fallacies - Appeal to authority: Minimal, mostly technical expertise appropriately referenced - False dilemma: Some oversimplification of security vs usability trade-offs #### Tone of voice - Overall tone: Technical, collaborative, solution-focused with appropriate urgency about security gaps ### 🛡️ DARVO Analysis - Deny: No denial patterns observed in technical security discussion - Attack: No attacks on accusers present - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Frustration with platform limitations expressed constructively ## 🎯 Conclusion The meeting reveals significant gaps between current npm security tooling and real-world security needs, particularly for enterprise users and solo maintainers. While trusted publishing was intended to improve security, its lack of proper two-factor authentication makes it unsuitable for most use cases. The discussion emphasizes the need for prioritized, actionable feedback to platform maintainers, with local publishing using ephemeral tokens emerging as the most practical secure workflow currently available. Future improvements require both platform-level changes and potentially architectural shifts toward kernel-level --- ## Full Transcript [00:13] Everyone, welcome to the September 29th [00:16] meeting of the OpenJS Security Collab. [00:20] Uh, good to see everyone. So, two topics [00:23] um are always good for walk-on topics if [00:25] we've got them. Uh but the first one we [00:27] wanted to talk about was npm publishing. [00:29] This is something we had talked about um [00:33] last week and around creating um some [00:37] guidance [00:39] and trying to make it not complicated [00:41] even though we think it will be [00:43] complicated no matter what. Um and [00:46] sounds like Wes you're going to prepare [00:48] a node collab summit session on the [00:50] above. So maybe you could talk a little [00:51] bit about that. [00:53] >> Yeah. Yeah. So um two-part. So last week [00:56] we uh also added to the agenda me doing [01:00] a talk on the main track uh with a [01:04] similar content. Um so the [01:10] I'll split up here a little bit and just [01:13] spend most of the time on the summit [01:14] here. But the uh I've started doing the [01:16] prep for the talk. Uh, I'll probably [01:19] send some notes to y'all for feedback [01:22] just to make sure that I'm, you know, [01:23] broadly not missing anything or or um, [01:27] you know, sending a message that we [01:29] think uh, could be better. Um but it [01:33] generally comes down to uh sort of four [01:39] reasonable setups [01:42] with pros and cons and really trying to [01:45] focus for those folks on how to think [01:48] about this problem. not necessarily to [01:51] propose them all uh like in depth with [01:55] details of why like I'll I'll talk about [01:57] pros and cons but those will be more to [01:59] point out like what works why it works [02:01] and why other things don't and then the [02:04] session which is where I think uh we [02:06] have more to do here will be to sort of [02:09] take some of this content uh make sure [02:12] everybody in our like you know [02:15] collaborator circle really understands [02:17] why this is important what the details [02:19] are and and dig into [02:22] particularly the like here's the only [02:25] working way and maybe this one kind of [02:28] works but you have to do you know X Y [02:30] and Z and then from that get a really [02:35] strong message to take back to the [02:37] GitHub and npm folks with like we hashed [02:40] this out at the collab summit session [02:43] and this is coming from the node core [02:46] you know and foundation you [02:49] collaborators, we're signing off on this [02:52] message. Here are the things we're [02:53] asking you to do to help us move this [02:56] forward. Um, and so that's kind of where [02:58] I'm thinking the session uh would [03:01] specifically like have that as a goal [03:03] for the outcome, which is why I think it [03:05] makes sense as a collab session, even [03:07] though it's not, you know, specifically [03:09] Node.js related like Node publishes a [03:11] bunch of packages. Um but really what I [03:14] want to get is like these are you know [03:16] core people in the ecosystem who have [03:19] agreed this is the the asks these are [03:23] the gaps that we're asking you know [03:24] GitHub uh to fill uh in the you know [03:29] immediate hopefully future. Um, [03:33] I think that's probably enough if folks [03:36] think that's Yeah. Okay. [03:39] >> I know. Um, I know we focus on the maint [03:42] maintainers and the the community [03:44] publishers here, but I'm wondering do [03:47] those same recommendations. [03:49] Are they the same recommendations for an [03:51] enterprise or a corporation to follow, [03:54] or are there different stronger [03:56] recommendations a corporation or [03:58] enterprise should follow? Um, I'd be [04:01] curious from that working for such a [04:03] large organization that's very [04:04] riskaverse. Um, but uh, so if I I guess [04:09] the maybe the the the [04:12] question to ask is is there something [04:14] corporations should be pushing on their [04:16] GitHub contacts and contracts and TAMs [04:20] and that kind of thing as well in the [04:22] meantime? [04:24] That's an awesome question and one that [04:26] I'm definitely have not put together a [04:29] clear answer for, but I also operate [04:31] the, you know, npm account for for [04:34] Netflix, so like, you know, I've I've [04:36] done this a bit. Um, [04:40] I probably will need to think about that [04:42] a little bit more deeply, but [04:45] uh most of these recommendations are [04:48] universal because they are not [04:51] necessarily about the type of org. It's [04:53] about the fundamentals of uh is it [04:57] resistant to automated publish? Is it [05:01] resistant to account takeover? Is it [05:04] resistant to mistakes being made in your [05:08] CI workflows or in your local developer [05:10] machines? [05:12] And those apply to us all. Uh I think [05:17] the things that [05:20] we probably need to dig into uh for [05:24] organizations and that so I I'll give [05:27] you a link uh once I'm done talking I'll [05:29] go find it. Um because I brought this up [05:31] in one of the community feedback things [05:33] is like we manage the tokens my team [05:35] manages the tokens for all of our folks [05:37] who Yeah. Okay. Yeah. And this whole [05:39] thing of them cycling those every seven [05:41] days is a nightmare. Like we can't do it [05:44] right. Um, [05:46] that would be, you know, I didn't use [05:49] the word nightmare in the post. Uh, [05:51] Jordan, though, I I you know, understand [05:53] why you said I think what you said in [05:55] the first one, but I it's like, you [05:56] know, I I did try to tone the language [05:58] back so that it felt, you know, um like [06:01] I wasn't on the attack mode. Uh but it [06:03] is [06:04] >> that makes it more more uh better [06:06] received anyway. So, that's [06:08] >> yeah, [06:08] >> a good idea. [06:09] >> Um but I mean, but it is frankly just [06:11] unt won't work, right? Uh and so [06:15] the problem is that the alternatives [06:18] uh don't provide [06:22] what any larger org needs first. Um we [06:26] do all this manually today. Uh it is a [06:29] big pain. [06:31] But the asks for that type of thing is a [06:34] lot more centered around automation uh [06:38] you know authentication integrations and [06:41] stuff like that which would improve [06:43] there and I don't think [06:46] that [06:48] those those asks are typically larger [06:51] and so if we're going to focus on [06:52] enterprises coming to ask that I think [06:54] we would need to sort of prioritize a [06:57] little bit because the fundamentals are [06:59] still not yet met right so like if push [07:01] us off tokens, the 7-day tokens, then [07:04] that means we our our only options are [07:07] non two-factor off options, which are to [07:10] me totally off the table, right? So that [07:13] so they basically your one good one that [07:16] was basically a you know uh a token with [07:20] enforced two-factor off is actually no [07:22] longer tenable because now you have to [07:23] renew that token every seven days and [07:25] the teams who manage the publish are not [07:27] the teams that manage the the access, [07:29] right? Um, so for orgs that that's [07:31] pretty impactful. Um, [07:34] sorry, I've got a whiteboard where I [07:35] wrote some of these out and I'm just [07:37] looking up at it to make sure I'm not [07:38] missing um [07:41] anything. Oh, and then the other thing [07:43] is the uh [07:45] uh removal. This I think was Jordan your [07:48] issue. The other one the um the T-top [07:51] removal or whatever is the that removal [07:54] would also impact this [07:57] >> workflow which is again just [07:59] a regression for for the users who need [08:02] that. Um, and their answer right now is [08:05] go to trusted publishing which has a [08:07] whole slew of, you know, we've got a a [08:09] whole slew of things we have to cover [08:10] with them before that can be actually [08:13] >> I mean and trusted publishing is it's [08:15] it's an incomplete feature anyway, [08:16] right? Like it doesn't it doesn't work [08:18] for a number of use cases. So it's just [08:19] not it even if it if using it would fix [08:23] all the problems which it doesn't it's [08:25] not possible for everyone to use it. So [08:27] it's just not a viable like thing that [08:30] to require everyone to do. Um would that [08:34] make sense if we uh describe uh very [08:38] clearly to uh especially for is for [08:42] maintainers solo maintainers uh in which [08:45] situations trust publishing wouldn't [08:48] work for that like uh in which case or [08:52] which scenarios they should not they [08:54] must not use that uh [08:56] >> all scenarios there is not a single [08:58] scenario today that is acceptable with [09:00] trusted publishing. [09:02] even for a solo maintainer. [09:04] >> No, especially for a solo maintainer. [09:06] So, uh it it actually is slightly more [09:09] secure in a multimontainer setup because [09:11] you can use your other maintainers as a [09:14] substitute for second factor. There is [09:17] no two-factor off setup that works with [09:21] the current trusted publishing. So, [09:23] basically, you're you end up relying on [09:25] GitHub [09:27] protected environments. [09:29] >> Yes. Yes. And [09:30] >> it only works if you have another [09:32] maintainer available to approve it. [09:36] >> And then that is [09:40] not resistant to account takeover. [09:45] So it is only resistant to automated [09:49] publishing [09:51] which helps with things like mistakes [09:52] and and that right. Uh but if your co- [09:56] if your if one of the accounts are taken [09:58] over [10:00] fully taken over here to be clear we [10:02] really actually mean fully taken over [10:04] not just fished into one step here but [10:07] like this would be you know uh [10:09] >> you can log in as the user on the [10:11] >> you can log in as the user and and take [10:12] and change their settings then right [10:15] that's what you need to do this so it's [10:16] not like a low bar here to be clear I'm [10:18] not trying to say as bad as what we just [10:20] saw with you know NX but as soon as that [10:24] happens now they uh they can add a new [10:28] user and it can be anybody and they can [10:31] then just go and approve their own thing [10:33] via their second [10:34] >> make a sock puppet account to be the [10:35] secondary. Yeah. [10:36] >> And so the only thing here that will [10:38] remedy that is if they build because [10:42] this doesn't exist today [10:44] off back into the npm side for trusted [10:48] publishing and then integrate it back [10:50] into the the um [10:51] >> Yeah. Yeah. Got it. or if they built the [10:54] thing that the RFC calls decided should [10:56] be built 5 years ago that they never [10:57] built staged publishing because then you [10:59] could publish from anywhere and then a [11:01] maintainer could use any form of two [11:03] factor multiple maintainers even to [11:04] approve and promote a stage publish but [11:07] it's unlikely and this is also in my [11:10] talk I am going to talk about uh a [11:13] substitute for staged publish here which [11:15] is that your automated pipelines uh [11:19] publish to a next disc tag and either [11:22] hard code that or do something that [11:24] basically makes a um you know [11:27] >> it slow roll and then you would have a [11:29] secondary workflow for the promote. It's [11:32] too factor. Yeah. [11:33] >> And that would help at least again make [11:35] it harder to do the what Shy Halude did, [11:38] which was just basically find everybody, [11:40] you know, anything and just publish 100. [11:43] >> That would work if npm added a way to [11:45] restrict new publishes to only being on [11:49] a on a set number of tags or certain [11:52] tags and basically disallow publishing [11:54] to go straight to latest. If you could [11:56] do that then like that would be perfect [12:00] and then it would be somewhat secure [12:02] especially if it was a one-way setting [12:03] that once you turned it on on a package [12:05] you couldn't turn it off. Um, [12:07] >> okay. So, we probably need resistance to [12:09] atto. [12:10] >> Okay. Okay. So, one way settings we need [12:11] to talk about. [12:12] >> Yeah, that's dangerous. [12:14] >> Well, it's not dangerous necessarily. It [12:16] is. Uh, it could be [12:20] >> Mhm. [12:20] >> fine. [12:22] Uh, [12:23] but there's a bunch of scenarios where [12:26] it takes somebody on the operational [12:28] side possibly having to do support work [12:31] that does not exist today to to make [12:34] that functional, right? So imagine one [12:38] user goes in and makes a setting change [12:42] without consulting the team [12:45] and we don't have package level uh fine [12:49] grain permissions today. So you are [12:51] either a fully trusted owner of the [12:54] package or not. And so because we don't [12:58] have that fine grain, it means that you [12:59] can't even onboard publishers unless [13:02] you've gone through and made sure they [13:04] are like [13:05] really experienced and know that that [13:08] setting is a one-way setting. And if you [13:10] go tick that box and hit save, [13:13] >> we now are stuck and we can't publish. [13:15] >> That's fair. And so you so they need to [13:18] then go on the have either support that [13:20] can very quickly undo the one way or [13:23] they need [13:25] workflows that undo the one way. Like [13:26] there's a whole bunch of like uh [13:28] operational features that would need to [13:30] be done to have that be true for either [13:33] trusted publishing or this you know [13:35] these other theoretical features we [13:37] would do if we wanted to go one way. Um, [13:40] and so I'm I'm when we talk about these [13:43] one way things, I think Marshall maybe [13:44] also made some suggestions about going [13:47] one way. I think there was some [13:48] suggestions on the GitHub releases being [13:51] one way once you go uh immutable uh was [13:55] another comment folks made. And both of [13:57] those have these problems, right? where [13:59] you either need to have the fine grained [14:01] off controls to make sure that's only in [14:03] the hands of your like you know core [14:05] folks or you need uh to have some [14:08] support workflow that can undo the one [14:10] way if it was done on accident. Um so [14:15] yeah [14:15] >> yeah that's fair [14:17] >> okay so uh uh the TLDD there is that do [14:21] not use th trusted publishing yet uh and [14:25] still keep using the npm tokens uh and [14:28] having a more secure uh uh workflow for [14:32] that. All right, makes sense. Um, yeah, [14:37] for essentially for for a single [14:39] maintainer project, I nobody has [14:41] provided me evidence to contradict that [14:43] the most secure approach is local [14:45] publish with a token that only lives on [14:47] a physical machine. So that it really [14:48] has to be a guy with a wrench or an [14:50] account takeover to to to hijack my [14:53] stuff. Um, for multiple maintainer [14:55] projects, as as was hinted, like [14:57] >> there it's a different trade-off. And [15:00] even though publishing from CI [15:02] approaches, which are almost always one [15:04] factor, they don't have to be, but they [15:06] almost always are. Uh even though that's [15:08] like objectively less secure in in a lot [15:12] of ways, it's for m multiple users [15:14] because it's auditable and you can [15:15] control permissions and stuff like there [15:18] may that may be a worthy trade-off, but [15:19] like those are your choices basically. [15:21] But but but in those cases of local [15:23] publishing with an existing token uh [15:26] that's stored locally, wouldn't that be [15:29] for instance the the recent event of the [15:32] supply chain attacks uh your token could [15:35] be leaked, right? Wouldn't it be more [15:37] safer if when you are publishing a new [15:40] package, you create a new token uh that [15:43] is that lives just once and then you [15:45] delete that? [15:46] >> Yeah. So that um [15:47] >> that's what I'm actually going to [15:48] recommend in the talk to be clear. Uh [15:50] okay. Yeah, [15:51] >> because that [15:52] >> Okay, so no spoilers. [15:54] >> No spoilers here. You know, if if if we [15:56] think there's another way, I mean, [15:57] Jordan, tell me if you think I'm wrong, [15:59] but I'm going to say what I was planning [16:01] to say at least is uh that this is our [16:05] let's start from scratch. Here's our [16:07] first experience here. And it turns out [16:09] it's actually probably the most secure [16:12] if you do X, Y, and Z. And then X, Y, [16:14] and Z was going to be uh login, publish, [16:18] and then delete the token locally. uh [16:21] which is all you actually have to do is [16:22] remove your npmrc. Now the token is [16:24] still valid uh on public npm but [16:28] presumably you if you do this workflow [16:30] where you uh npm log in npm publish npm [16:36] log out [16:38] uh you [16:40] that token is ephemeral in that like [16:43] nobody's going to they'd have to hack [16:44] npm to steal it and at that point [16:48] >> and actually I don't even they probably [16:49] they'd have to crack it you know what I [16:51] mean like we're talking [16:52] >> to replace the the binary Yeah. [16:54] >> So, what I would what I would suggest as [16:56] a modification to that is because it's [16:59] really annoying if you have to do it [17:01] each publish is that you can set a you a [17:05] setting in your npmrc so that on every [17:07] time you run npm publish as like a pre [17:10] pre-publish it gives you a URL that you [17:13] have to visit to get a token. You get [17:15] the token, you paste it in the prompt [17:17] and then it keeps it in your npmrc even [17:19] but uh it lasts for a period of time an [17:22] hour, two hours, a day, whatever [17:24] something finite and then uh and then [17:28] you can reuse that and so like and then [17:31] it becomes if it can be invalidated [17:33] after that period of time then it [17:34] doesn't matter if you delete it you just [17:35] keep it until npm tells you oh you need [17:37] a new one now [17:39] >> and love this but [17:42] >> uh that needs to be npm building that. [17:44] So I'm correct [17:45] >> specifically talking about things you [17:47] can do today. [17:48] >> Okay, got it. [17:49] >> And then the session, this collab summit [17:52] session is where I want to really dive [17:53] into these type of things and say is [17:56] that is asking that is that better than [18:00] asking this, you know, other workflow. [18:02] Like when we're going to ask them [18:03] something, we need to be crisp about [18:05] like this is the ranked order of [18:08] importance. [18:10] We understand like and you know you were [18:12] on uh actually oh I think you made you [18:14] may miss the call with Leo right? Uh [18:16] >> uh yes I did. I was on a plane at the [18:17] time [18:17] >> because Leo was making very clear we [18:20] have limited time. We have to be very uh [18:23] uh ruthless in prioritization so that we [18:26] can get the things that are most [18:27] important done. And so what I'm want to [18:29] come out of that with is actually like [18:31] stack rank these as a you know feature [18:33] request list and be like if you do none [18:36] of the other ones this top one is the [18:38] one we're really asking you for first [18:40] right and so like that workflow sounds [18:43] great uh but like today what that would [18:47] need is like some new APIs so right they [18:49] don't even have APIs for user management [18:51] at all zero right uh you have to back [18:55] you know uh [18:58] engineer them from the website requests [19:00] and like those are not stable so like [19:02] don't go do that uh right so like manual [19:05] is what you have here and so what I'm [19:07] doing in the talk is really saying here [19:09] is a manual workflow that works today if [19:11] you are a maintainer and and this local [19:14] one is it's what I do most of the time [19:17] I'm not you know perfect nobody is but [19:19] like I get my project ready to publish I [19:24] run npm login I publish it with [19:26] two-factor off and then I I just delete [19:29] the npmrc entirely because I don't keep [19:31] a local npmrc but like you know you can [19:34] also npm log out uh and then that [19:38] achieves this primary goal here if you [19:42] want to go the extra mile. I'm also [19:43] going to mention going into because I [19:45] don't think people know this. You have [19:46] to go into the npm UI and delete the [19:48] tokens uh for them to actually be [19:51] revoked. Uh npm logout doesn't actually [19:54] do that. it just deletes it from your [19:55] local system. Uh so like again I'm gonna [19:58] that's the like local uh recommended [20:02] workflow there. [20:05] And then I did want to add one last [20:07] thing here on top of Jordan's uh nobody [20:11] has presented one that is uh good enough [20:15] or whatever comment. Sorry I don't [20:16] remember. I'm missing your words. But uh [20:19] I do think that there is a CI publish [20:24] workflow that is good enough. [20:28] It does include third party integrations [20:31] so that you can do [20:34] second factor [20:36] and I think that is good enough and I [20:38] think Jordan you even use that somewhere [20:41] >> in one yeah so the the in one project I [20:44] use it I use a granular publish token so [20:46] for only that package and but it relies [20:48] on a third party server so it only works [20:51] because I have a third party server I [20:53] trust that's not practical for to demand [20:55] of or expect of open source people If uh [20:58] GitHub could build something natively [20:59] that uh removed the need for a third [21:02] party server, then that is what everyone [21:04] should do. [21:05] >> But just to be clear, the third party [21:06] integration only handles the the one [21:09] time [21:10] >> it only handled inputting an OTP token [21:14] and putting it into a thing. [21:16] >> Even the trust there is reasonable in [21:18] that they don't that's they only have [21:19] one factor. So, as long as you have what [21:22] you mentioned, a granular access token, [21:25] which [21:26] enforces two-factor off, even the third [21:29] party couldn't publish on your behalf [21:32] because all they're handling is the OTP. [21:34] >> That's true. [21:35] >> And so, I think that that's [21:39] requirements. [21:40] >> I don't I wonder how many OTP codes it [21:43] would take to reverse engineer the seed, [21:45] but um that would be other than that, I [21:48] think you're right. valid uh and you are [21:52] this is why you know you're thinking [21:54] this is what we need uh but also uh I [21:57] think it's higher number of publishes [21:59] than any package on current npm. [22:02] >> Yeah that that's likely. [22:06] So, I I think that one So, I think [22:08] there's two coming out of this. Like, [22:10] I'm I think there's really two here that [22:13] work. Um, [22:15] and then there's two that are [22:20] some people will call it good enough. [22:22] Uh, [22:24] and I will call those out, but I don't [22:26] call them good enough. And then I think [22:28] they apply universally to anybody [22:30] publishing packages depending on their [22:32] own personal risk assessment. Um, you [22:36] know, like I think for like an org, like [22:39] Steve, this is where this started here. [22:40] We went on a bit of a deep dive, but [22:42] like for an org, having people, you [22:44] know, get tokens and put them on their [22:45] local machine is probably not, uh, you [22:50] know, what most orgs are going to want. [22:52] Um, what we do is we mint them and, uh, [22:57] encrypt them with one of our internal, [23:00] uh, you know, security tools. uh and [23:03] then granularly hand out access. Uh and [23:07] those are all backed by, you know, [23:09] two-factor off and all sorts of other [23:11] stuff that that make that more [23:14] reasonable. Um but still turn on [23:17] two-factor off. So like again it comes [23:20] back to the same thing of like the the [23:23] orgs have to do the same thing and we [23:24] should really make it easy for the orgs [23:26] because if we make it easy for the orgs [23:27] we'll make it easy for everybody because [23:28] orgs have it worse by having to manage [23:30] so many you know users and complicated [23:33] things. [23:42] Should we move on to the next topic [23:44] which is related to this topic but maybe [23:47] get concrete? Um so this was the ask [23:50] around um defining topics for the [23:51] Node.js collapse summit. [23:53] >> Uh actually I think this is what uh I I [23:57] don't know exactly. Uh maybe we might [24:00] have something different for Noode.js [24:02] itself but uh I think it's all in the [24:05] same uh in the same discussion right [24:09] Wes. [24:12] I think it feels that way. Yeah, I mean [24:15] I am I am I will say I think I multiple [24:19] times I have mentioned this to folks and [24:22] they have brought up other supply chain [24:25] things like I was going to like your [24:28] comment in the chat right here about [24:30] checking the sham of the binary right [24:33] that is actually not the main focus of [24:36] what I'm trying to get at there's [24:38] holistic supply chain security I'm [24:41] specifically trying to get toward like [24:42] what are the publish settings and what [24:44] are the workflows that are that are [24:46] there feels like there's something here. [24:48] So like you said checking the npm you [24:51] know binary for malicious you know [24:54] modifications uh uh uh Bishek uh ner I [24:58] don't know if you all are familiar um uh [25:01] with him he's uh works on lavaote when I [25:04] brought this up on blue sky was like hey [25:06] I hope you're going to mention not [25:08] running in post install scripts and [25:09] here's my lava mo package for that I [25:12] think there's more to it so if we wanted [25:14] to do two and talk about like the other [25:18] stuff [25:20] like I feel like there's definitely room [25:22] for that [25:25] >> but from nojs perspective what else we [25:28] can do because I I think the initial [25:31] idea of the permission model was to uh [25:34] prevent those access uh if the whenever [25:38] you uh people try to have a a post [25:41] installing script that executes a nojs [25:44] binary they will inherit the the parent [25:48] permission model flags and then you know [25:51] it could have some some some prevent [25:53] some attacks but I don't know what else [25:55] we could do from nojsi. [25:57] >> Yeah that's the kind of stuff the [25:59] permission model is the stuff I was [26:00] thinking where we could like probably [26:02] brainstorm a bit and come up with some [26:04] good you know I I did copy your safe npx [26:07] script and I I made some modifications [26:09] for myself but like expecting users to [26:11] do that seems pretty low. So it [26:13] definitely feels like for a whole bunch [26:15] of those kind of [26:16] >> when you're when you're talking about [26:18] mechanisms for maintainers, you can [26:20] recommend workarounds and and and [26:22] complex flows. When you're talking about [26:23] protections for users, pretty much [26:25] anything like it's it's great to be able [26:27] to say, hey, if you're really worried, [26:29] this is the things you can do, but [26:31] unless it's changing the defaults, it's [26:34] basically not going to move the needle [26:35] in my opinion. Um, and for npm install, [26:39] only npm can change those defaults. [26:43] and node can make strong recommendations [26:45] and if there's features right like if we [26:47] could find a permissions model set of [26:50] settings [26:52] >> that worked for some 80% case I don't [26:57] know what we'd want to set as a bar to [26:59] then recommend to npm to implement and [27:02] then if there was other additional you [27:04] know user experience changes that need [27:06] to happen because frankly I I you know [27:07] the permissions model [27:10] in a real project is like a nightmare [27:13] because they're just the user is just [27:15] getting peppered with with like I don't [27:17] know should it be able to read that? I [27:19] don't I just some random [27:22] >> package that's in my transitives. Deno [27:24] and Android and stuff have that type of [27:25] permission model and and users like like [27:29] pretty empirically do the exact same [27:31] thing they do with like terms of service [27:32] agreements is they just go agree agree [27:34] agree approve approve approve and like [27:36] it's a great idea until everyone gets [27:39] tired of it and that happens very [27:40] quickly [27:42] >> like the the major flaw with OKAP as a [27:45] thing is that like [27:46] >> it's it's not like humans don't don't [27:48] want to do that [27:51] >> there is there's there are some some [27:53] settings that could apply globally in [27:55] case of npm. Uh we have mentioned that [27:58] some some flags could only be changed if [28:00] npm changed the the full but uh in case [28:04] of uh the environment variable node [28:05] options you can you can make that global [28:08] and basically whenever you run npm uh it [28:11] will uh get that node options by def [28:14] whenever it spawns a nojs process. So if [28:17] you define that that you want to have [28:19] the permission enabled to any NodeJS [28:21] process that might work. Uh but as as [28:25] Jordan mentioned uh if you run uh you [28:29] need to define a set of policies for [28:32] each project and that might be a [28:33] nightmare that that might be no that [28:35] that will be a nightmare because a lot [28:38] of uh projects they read from different [28:40] files and on on the startup they if they [28:43] are reading from open SSL configuration [28:46] they need to understand why they are [28:47] reading that and why that's the def uh [28:50] but yeah uh that that's [28:54] And then to add on top of it the recent [28:56] attack uh [28:58] you know and I I have to look into it I [29:00] haven't tried to set this up but uh [29:02] spawning processes means that the [29:05] permission model there [29:08] right won't be transitive so you you [29:11] know set the permission model in npx and [29:13] then npx goes off and the what was the I [29:16] I don't think this attack got a name [29:18] this was the first in the series of [29:20] attacks here over the past month. Um, it [29:23] was the one that used uh local AI agents [29:28] to actually like pick up and find all [29:31] the the tokens on the machine. So what [29:35] they did is they used node uh I can't [29:38] remember specifically which was it [29:39] exeact file to call claude and whatever [29:44] all these other uh local binaries [29:48] uh are and those are the what they [29:50] actually did to do the work. I don't [29:52] know if you all saw this. There's a good [29:53] blog post I can find the link to, but [29:55] basically they just based in all the [29:56] unsafe flags. And so basically they used [29:59] node as the entry point, but as long as [30:02] the node process had child process exec, [30:06] they basically had a free reign. And so [30:08] they exec, you know, the the claw to [30:12] basically say unsafeely run all these [30:14] commands and now you've escaped the [30:15] sandbox. So you need like a little bit [30:18] more right than just [30:22] >> whenever you uh enable the permission [30:25] model the exac and spawn are blocked by [30:27] the fool. So that would would prevent if [30:32] this is the is the entry point. [30:33] >> But but the point is then you you get a [30:35] reasonable use, right? So the reasonable [30:38] use here is that almost every tool [30:42] that you have to run in an XP npx style [30:46] calls spawn in some form. And [30:50] >> yes, [30:50] >> maybe they shouldn't, but they all do [30:53] for reasons. And so then as soon as you [30:55] enable it, you now have enabled it for [30:58] all [31:00] use cases there, which could then mean [31:03] you enabled it for one you know it [31:04] needed to do and you got one you didn't [31:07] want. [31:08] >> Yes. Uh if you spawn a no.js process [31:12] from a nojs process, the permission [31:15] model flags are inherit. So if you don't [31:17] have access to the parent, you don't [31:19] have in the child. But you can print [31:21] that on a bash script. Yeah, exactly. [31:24] That's literally what I was going to [31:25] say, which is what they did. They [31:26] spawned, you know, the the [31:28] >> the inheriting mechanism is environment [31:30] variables, which you can override when [31:31] you launch anything [31:35] >> like there's no there's no way in [31:36] computers to like only allow you to [31:40] launch like to force you to to propagate [31:43] those that policy down. So, it's just [31:45] it's not effective in that regard. [31:49] >> Yeah, that makes sense. [31:50] >> Yeah. So I I feel like there are [31:51] improvements here and I think there's [31:53] probably user experience things that we [31:55] could talk about on how to make policy [31:58] API more functional for real projects. [32:02] Right? Again all four of this like let's [32:05] >> give some people some suggestions on how [32:07] they can do it a little better. But I [32:08] look at things, you know, like um like [32:11] Lavaote and uh what's the other one that [32:15] uh uh [32:18] >> SCS [32:19] >> chain guards thing or well yeah [32:22] whatever. Like there's a [32:23] >> chain no chain guards thing is just like [32:25] uh [32:26] >> I was trying to broaden [32:27] >> they're giving you images that have been [32:29] checked already. [32:30] >> Sorry. I was trying to broaden the [32:31] umbrella. Yeah. So all of these things [32:34] that sit outside of this that are trying [32:36] to help improve, right? So chain guard's [32:39] thing is one check, right? There's the I [32:41] think uh node source has some verified [32:43] modules thing as well. Uh [32:47] >> so has a wrapper. [32:48] >> Socket has a rapper. All these things [32:50] that sit outside are great additions to [32:53] the ecosystem that we can recommend, but [32:55] they don't work for everybody because [32:57] they will have different levels of [33:00] opinions, right? like some things, you [33:03] know, would if I tried to roll them out [33:04] at work, nobody would be able to adopt [33:06] them. It would break everything, right? [33:08] And like I can't so I I'm my hands are [33:10] tied. Even though it might be more [33:12] secure, I can't do that, right? And so I [33:14] think we'd all have a different list of [33:16] what those things are. And so there's no [33:20] like fundamental, you know, nugget [33:22] there, whereas like permissions model [33:24] enables it via the platform so that [33:26] those people could take different [33:29] opinions. [33:29] >> Yeah. So there there's one thing that we [33:32] are experimenting and that also b uh uh [33:35] related a bit with a talk that toas did [33:39] to node confl [33:47] support to node.js JS that basically uh [33:50] the the problem of the permission model [33:52] is that we relies on file paths. We [33:54] don't rely on on resource which means [33:56] that if you spawn another process uh [33:59] that could be rejected and there are [34:01] many ways there are many educates you [34:03] need to cover and most of the time you [34:05] won't be able to cover all of them. uh [34:08] uh but once you uh start start to [34:10] restrict that by uh by the kernel uh [34:13] using ebpf you you can be way more you [34:16] can definitely create a sandbox for that [34:19] uh if that's in the scope of node.js JS [34:22] or not. Uh that's up to discussion [34:25] because uh a lot a lot of companies they [34:28] create a ecosystem around that and [34:31] that's uh that's unrelated to the [34:33] platform they're using. If they're using [34:34] PHP, if they're using NodeJS, uh it just [34:37] works. Uh but this is an research and [34:40] there is one t that did for nodecom [34:44] which is basically it creates a sandbox [34:47] by the terminal. For each terminal [34:49] process, they have a kind of uh uh [34:53] mechanism that send box all the commands [34:55] you run to to make it safer. Uh and that [35:00] prevents some leak uh if you are trying [35:03] to read from a file where you don't you [35:05] don't have access or if you are trying [35:07] to respond a process, it's kind kind of [35:10] auditable. Uh but yeah, that's that's a [35:13] long discussion. [35:17] It sounds to me like we have enough for [35:18] another session. [35:20] Like, right. I mean, this feels we've [35:23] just spent almost the entire meeting [35:24] talking about these things. It feels [35:26] like we have [35:29] we could do them back toback or I don't [35:31] know if people would be overwhelmed with [35:33] too much security deep thinking. Um, but [35:36] like it feels to me like there's a lot [35:38] to talk about here. [35:45] Do you want to I guess the action item [35:47] here would be do we want to make another [35:49] proposal? I can't run another thing. [35:51] It's too late for me to sign up for [35:52] that. But Raphael, I would totally be [35:54] thereating. [35:56] >> I actually would like to uh instead of [35:59] creating a different proposal, we just [36:01] extend your proposal a bit. Uh maybe uh [36:05] from 30 minutes to 1 hour and then we [36:08] start uh from npm and then we jump to [36:11] no.js. you we you know because they [36:14] overlap a bit uh and uh I don't like [36:17] context switching. So imagine going to a [36:20] different meeting you know like maybe we [36:22] can find good things there. [36:25] >> That works for me. Uh James is my uh [36:30] volunteer on partnering on that and he [36:31] is not here. Um but I could start a DM [36:34] maybe [36:36] >> with you and him and just say hey we [36:38] were on the security thing. He's I mean [36:40] he's you know pretty flexible here I [36:42] think but he was definitely more focused [36:43] on the publishing aspect because you [36:46] know they he was looking at pinos and [36:48] Matteo had you know [36:50] >> we have been discussing that for a fest [36:52] five. [36:52] >> Yeah that's what I that was why he was [36:54] you know into it. Um [36:55] >> well and I'm not going to as I told you [36:57] Wes like I'm not going to precommmit to [36:59] doing organizational work on it but like [37:01] I will be as available as you need [37:04] during the session. [37:06] >> Yeah. [37:07] >> To help in whatever way. [37:08] >> Okay. That that Yeah. So sounds like [37:09] maybe yeah I'll just start a DM [37:13] maybe with anybody who wants to be a [37:16] part of just being you know ensuring [37:18] that we have the right uh uh scope set [37:23] for it and then uh yeah if we make it an [37:26] hour [37:27] you know we can I can [37:30] I can help I I won't be in person but I [37:33] can definitely help with uh uh [37:36] discussions and uh you [37:39] bring some ideas. [37:42] >> Cool. Uh, okay. I'll start a DM uh right [37:44] after we're done with the call. [37:52] >> Okay, I think that was actually our well [37:56] beyond our official agenda. Uh, is there [37:59] any other things that folks want to [38:00] discuss in the few minutes we've got [38:02] last left? [38:06] Uh maybe a public uh happy uh birthday [38:09] for Robbie. [38:11] >> A thank you [38:14] again. All my favorite peeps community [38:16] day. [38:19] >> Awesome. All righty. On that positive [38:22] note, I think we'll adjourn. Uh thank [38:24] you all. Uh see you next week. Bye. [38:26] >> Thanks all.