---
# System prepended metadata

title: Open RFC Meeting (npm)

---

#### 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
	1. Outline Intentions & Desired Outcomes
	1. Announcements
	1. Introduction(s)
1. **PR**: [#593 Only Registry Dependencies](https://github.com/npm/rfcs/pull/593) - @thescientist13
1. **Issue**: [#622 [RRFC] include context that a module is overridden in npm ls](https://github.com/npm/rfcs/issues/622) - @bnb
1. **PR**: [#626 RFC for linking packages to their source and build](https://github.com/npm/rfcs/pull/626) - @feelepxyz
1. **PR**: [#23 Add Singleton Packages RFC.](https://github.com/npm/rfcs/pull/23) - @usergenic

### Notes

#### **PR**: [#593 Only Registry Dependencies](https://github.com/npm/rfcs/pull/593) - @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?

#### **Issue**: [#622 [RRFC] include context that a module is overridden in npm ls](https://github.com/npm/rfcs/issues/622) - @bnb
- @ljharb
  - `overrides` are not represented in `npm ls` or `npm explain`
- @nlf
  - this is a bug
  - need to fix

#### **PR**: [#626 RFC for linking packages to their source and build](https://github.com/npm/rfcs/pull/626) - @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)
  - 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

#### **PR**: [#23 Add Singleton Packages RFC.](https://github.com/npm/rfcs/pull/23) - @usergenic
- ...
