Page MenuHomePhabricator

Determine Node package auditing workflows
Open, Needs TriagePublic


Descoped from T199004: RFC: Add a frontend build step to skins/extensions to our deploy process
Next step in the sequence: T257061: Evaluate the workflows and workload of managing a Node package repository

This ticket is about discussing package vetting practices, tooling and their output (libraryupgrader2).

NOTE: This is a placeholder ticket to lift this discussion from the parent RfC. It would be appreciated if a developer familiar with local practices and tooling could write a proper description and title.

Event Timeline

@Demian: Please add project tags - thanks.

Done. I'm in the dark with that, so I wasn't in a hurry to do so. I hope I found the right project.s
Note for the future: one comment will be enough. In fact, without comment I would have done once I figure out the projects.

Initial thoughts republished from wikitech-l:

100% review wouldn't be sustainable IMO (causing developer burnout very quickly), but looking for specific patterns exhibited in malicious packages could be a successful approach to increase trust in the audited code. Patterns like:

  • An unmaintained repo receiving an update, which is a common solution to inject malicious code.
  • New packages added to the dependency tree.

An interesting article in this regard:
The repo of former malicious packages is also worth mentioning: npm-zoo

I think a 2 stage deployment process would increase security:

  1. An auditing package repository with all the updates to be vetted. This would be used in sandboxed environments to expose updates to developers, who could notice outstanding behavior, warning signs.
  2. A stable package repository for CI and not sandboxed environments.

The review process:

  1. The auditing repo only includes packages used in WMF projects.
  2. Package versions need to be greenlighted for auditing too. This is preceded by a basic check of the validity of that version to look for eg. injections using stolen credential, but code is only reviewed if suspicious, eg. new packages, unexpected updates.
  3. Package versions would stay in this stage for some time (eg. 2 weeks), depending on the package and urgency.
  4. A changelog in the auditing repo tracks the newest updates, informing developers about what packages to pay attention to.
  5. One of the developers dedicated to package vetting does a deeper review of the code. This should be aided by heuristic tools.
  6. When confidence in a version is built, that version is greenlighted for the stable repo.