- Darcy Clarke (@darcyclarke)
- Philip Harrison (@feelepxyz)
- Nathan LaFreniere (@nlf)
- Gar (@wraithgar)
- Eddie Zaneski (@eddiezane)
- Zach Steindler (@steiza)
- Jordan Harband (@ljharb)
- Brian DeHamer (@bdehamer)
- Owen Buckley (@thescientist13)
- Nathan Fritz (@fritzy)
- Rick Markins (@rxmarbles)z
- Housekeeping
- Code of Conduct Acknowledgement
- Outline Intentions & Desired Outcomes
- Announcements
- Introduction(s)
- PR: #593 Only Registry Dependencies - @thescientist13
- Issue: #622 [RRFC] include context that a module is overridden in npm ls - @bnb
- PR: #626 RFC for linking packages to their source and build - @feelepxyz
- PR: #23 Add Singleton Packages RFC. - @usergenic
PR: #593 Only Registry Dependencies - @thescientist13
- @thescientist13
- investigating
npm query
- updated the RFC
- investigating
- @ljharb
- would love for a
semver.npmjs.com
-esque experience - we should have
npm audit
be an umbrella command for all these types of types of checks - current defaults for
audit
are"vulnerabilities"
& it's logging/type is"warn"
- would be nice to not have to require a reified node modules to be able to use
npm query
- would love for a
- @feelepxyz
- like this proposal
- can this gate installation?
- @ljharb
overrides
are not represented innpm ls
ornpm explain
- @nlf
- this is a bug
- need to fix
PR: #626 RFC for linking packages to their source and build - @feelepxyz
- @feelepxyz
- introduces a new way to attest a source build is the origin of a package
- prevents package hijacking attacks (ex. npm credentials are stolen, modifies the package & publishes to the registry)
- linking doesn't actually prevent this
- gating 2fa would help with preventing this as well
- @ljharb
- would be good to know what attack vectors this protects against that have actually been exploited? (as opposed to theoretical POCs that haven't actually been exploited)
- maximally backfilling npm packages should be a high priority, especially ones without a build process
- vs. annotating new packages
- there's developer friction to publishing from CI
- there's no way to compromise my personal 2fa today without compromising all of my credentials at once, which would defeat any automated approach that checks for authenticity.
- @steiza
- this is not a one size fits all security capability
- @ljharb
- concerned about creating perverse incentives do push the ecosystem in a direction
- ex. typescript support/typescript badge being added to package pages on
npmjs.com
(maintainer doesn't have to include types, they can be submitted by the community to DT)
- ex. typescript support/typescript badge being added to package pages on
- have been publishing from local machine for a decade, history proves this is trustworthy for most authors
- could be harmful to the ecosystem/maintainers because it faults them for not publishing in this particular manner
- is there a way we can "special-case adopt" existing/legacy publishes into this security/attestation so they aren't penalized
- seems like there's other missing metadata about the linkage between packages & source repos
- concerned about creating perverse incentives do push the ecosystem in a direction
- @steiza
- we'll want to be careful about how we phrase this repo linking, e.g. careful not to show a verified check that penalises legacy packages
- have not scoep this yet for legacy packages
PR: #23 Add Singleton Packages RFC. - @usergenic
- ...