Skip to content

Latest commit

 

History

History
102 lines (91 loc) · 6.93 KB

2020-09-16.md

File metadata and controls

102 lines (91 loc) · 6.93 KB

Meeting from: September 16th, 2019

Open RFC Meeting (npm)

Attendees

  • Darcy Clarke (@darcyclarke)
  • Christian Siebmanns (@christian24)
  • Isaac Z. Schlueter (@isaacs)
  • Mark Dodgson (@doddi)
  • Ruy Adorno (@ruyadorno)
  • Nathan LaFreniere (@nlf)
  • Jordan Harband (@ljharb)
  • Wes Todd (@wesleytodd)

Agenda

  1. Housekeeping
    1. Introduction(s) (ex. note the name of the call, state the week day & date)
    2. Code of Conduct Acknowledgement
    3. Outline Intentions & Desired Outcomes (ex. want to interact with the community to ensure that there is movement on important issues/ideas for the project)
    4. Announcements
  2. PR: #224 RFC: No auto-install for peerDependencies marked as optional - @jrylan
  3. PR: #217 RFC: add registry per package per organisation - @baloran
  4. PR: #195 RFC for check engines requirements on every install - @markablov
  5. PR: #138 RFC: Add `npm-app-id` HTTP header - @Mykyta
  6. PR: #18 npm audit and audit-resolve.json - @naugtur
  7. Issue: #223 [RRFC] npm audit for a not yet installed package - @Christian24

Notes

  • npm v7.0.0-beta.11 shipped this morning

#224 RFC: No auto-install for peerDependencies marked as optional

  • Landing during the v7 beta period
  • ruy: there's some open questions in PR?
  • "autoinstall: false" feels bad though, double-negative problem
  • Darcy to follow up with the PR

#217 RFC: add registry per package per organisation

  • Darcy: Not a lot of discussion in the PR and it doesn't seem to be controversial
  • Isaac: Not a breaking change, we could land it on a minor version just fine
  • Ratified 👍

#195 RFC for check engines requirements on every install

  • Jordan:
    • By default engines mismatch are a WARNING not a failure
    • Even if it becomes an ERROR there should be warnings that let you know of the problems
    • There should be a way to be warned about it when swaping node versions even though node_modules/package-lock hasn't changed
  • Isaac:
    • There's nothing in the proposal changing the warning by default behavior
    • We should get it in during v7 beta period since it might be sort of a breaking change

#138 RFC: Add npm-app-id HTTP header

  • Isaac:
    • Adding new property to package.json needs some double-check to make sure no one is using that metadata field in the larger ecosystem
    • Maybe bikeshed in the name of the property?
      • If the usecase is header names and values to be send to the registry maybe a headers name is better than metadata
      • app-id we checked before and does not seem to be used
  • Darcy: headers makes a lot of sense as a name but would need that double-check with the ecosystem to make sure it does not colide with other tools
  • Isaac: What happens when people drop something other than header key/value in that property?
  • Wes: That can be really valuable to send arbitrary metadata to the registry
  • Isaac: You can add any type of data there that will always be attached to requests when communicating with the registry
  • Isaac: Concerned that we might be adding a subtle type of config that changes the behavior/result of commands (specially in regards with the registry)
  • Isaac: The original usecase to just submit one extra header to audit is a much more scoped one
  • Darcy: This could make more sense as a proper .npmrc config value
  • Mark: Needs to be per project appid
  • Isaac: It's supported to have project-level .npmrc files that can be committed and hold that data
  • Darcy: Any pushback that would make it NEED to be in package.json ?
  • Isaac: Suggestion is to make a config that would accept headers as key/value pairs
  • Nathan: Having things like headers in the package.json opens the door for folks to add secrets/tokens in there and eventually leaking them
  • Darcy: .npmrc is by default ignored so there's less of a security concern having it there
  • Wes: Have seen the example of people leaking their npm token by pushing .npmrc config files to github
  • Isaac: The headers config doesn't worsen the problem, just keeps the same sort of security concerns that using configs have today
  • Darcy: Let's rename the PR itself to not mention appid
  • Isaac: One more idea: The cli could also read headers sent by the registry server in order to store it to the local .npmrc config
  • Darcy: It can be a separated RFC
  • Isaac:
    • Sure, this second separate RFC can be build on top of the first one that adds support to the headers config
    • Server wants to define an unique id for projects, if it doesn't get a appid header, it sets one to the response so that the cli can parse it and set it on the client side
    • Also bypass human problems of getting a wrong appid in place
    • Server can also add a npm notice to notify users that the config got automatically added
  • Mark: Can work on the second follow up RFC too 👍

#18 npm audit and audit-resolve.json

  • Darcy: Recently have a discussion in the Node.js Package Maintenance Working Group
  • Wes: Original RFC is to support an audit triage list at the consumer level, the current discussion from the working group evolves into fechting a triage list maintained by the cve/advisory publishers (snyk, github, npm, etc)
  • Darcy: Main change is switching away from audit-resolve.json into looking for these providers to find this extra triage list
  • Ruy: Does it makes sense to even follow up with this RFC? Maybe we need a new one altogether
  • Wes: The final user could just maintain a list of these providers to reach out for a triage list, it can be that even a local file is one of these providers

#223 [RRFC] npm audit for a not yet installed package

  • Christian:
    • Throwing the idea out to see if folks think that's something valuable
    • Learn in advance wether a package has current security issues open against it
    • Sourcing feedback prior to opening a new RFC to describe this
  • Isaac:
    • With the new arborist/audit implementation + registry quick audit endpoint it's much more simpler to actually implement this
    • Should also inspect the subtree for the given package spec in order to determine if there are vulnerabilities
  • Wes: [side discussion]: Should also include vuln changes to the packument
  • Isaac: That's a much harder problem to tackle
  • Darcy: Sounds like this is a better feature to live in npm view
  • Ruy: In the cli we should mind that if we're talking about adding subcommands to npm audit adding a resolution to package specs there might limit what we can do in the future
  • Christian to follow up and write an RFC