Skip to content

Latest commit

 

History

History
78 lines (69 loc) · 3.82 KB

2022-08-10.md

File metadata and controls

78 lines (69 loc) · 3.82 KB

Meeting from: August 10th, 2022

Open RFC Meeting (npm)

Attendees

  • 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

Agenda

  1. Housekeeping
    1. Code of Conduct Acknowledgement
    2. Outline Intentions & Desired Outcomes
    3. Announcements
    4. Introduction(s)
  2. PR: #593 Only Registry Dependencies - @thescientist13
  3. Issue: #622 [RRFC] include context that a module is overridden in npm ls - @bnb
  4. PR: #626 RFC for linking packages to their source and build - @feelepxyz
  5. PR: #23 Add Singleton Packages RFC. - @usergenic

Notes

PR: #593 Only Registry Dependencies - @thescientist13

  • @thescientist13
    • investigating npm query
    • updated the RFC
  • @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
  • @feelepxyz
    • like this proposal
    • can this gate installation?
  • @ljharb
    • overrides are not represented in npm ls or npm explain
  • @nlf
    • this is a bug
    • need to fix
  • @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)
    • 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
  • @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
  • ...