d***@mozilla.com
2018-11-29 21:22:54 UTC
[For those who have seen earlier iterations of this document, the security section now discusses the recent event-stream/flatmap-stream exploit specifically --dmose]
I’ve drafted a set of straw man proposals for getting basic node_modules support in mozilla-central sooner rather than later. The intent here is to make it possible for us to vendor in non-trivial JavaScript tooling for teams/maintainers who want to improve their efficiency. In this context, “vendor” is being used to mean “review, land, and maintain 3rd party software packages” in mozilla-central.
Once it’s clear that we have rough agreement about the linked policies, I’d like us to [vendor in eslint] (https://bugzilla.mozilla.org/show_bug.cgi?id=1491028) so that we can test these policies against something real as we continue to discuss and iterate on them.
This is NOT an exhaustive analysis of the various pros and cons of all the options available for using and handling node_modules. Whatever gets decided now, it’s all subject to reconsideration in the future, as we gain more experience with NodeJS and node_modules in mozilla-central.
In order to make it possible to have a high-level overview of the proposals, here is a table of contents into the policy doc with links:
High level proposal: we [vendor packages into /node_modules]
(https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.kfwtdxmvgnnh)
Vendoring Concerns/Proposed Policies:
* Proposed policy: node_modules currently for use at build-time only, to accelerate initial implementation. (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.1ymboxqoh497)
* Proposed policy: disallow modules with binary executables in mozilla-central except in critical cases to avoid differences between cross-platform builds and binary checkins. (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.ukei1hiusud0)
* License compatibility: choose a list similar to that used by `mach vendor rust`, vet with legal, automate (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.gfwanflj694p)
* Security/trust: landing time reviews, regular automated vulnerability scans (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.y6mzqzu3kg6u)
* Avoid importing tools with with their build-systems that don’t expose their build Directed Acyclic Graphs (i.e. the graph of all dependencies from inputs to outputs) (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.vn1vq8p5uod6)
* How to vendor in -- draft checklist (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.90qxauq1a5vs)
Node Engine concerns (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.tp8br5vz41jy)
* nodejs/npm version changes & security updates
* ability to build old versions (e.g. old ESR releases), given that node is coming from CI artifacts?
I’ve drafted a set of straw man proposals for getting basic node_modules support in mozilla-central sooner rather than later. The intent here is to make it possible for us to vendor in non-trivial JavaScript tooling for teams/maintainers who want to improve their efficiency. In this context, “vendor” is being used to mean “review, land, and maintain 3rd party software packages” in mozilla-central.
Once it’s clear that we have rough agreement about the linked policies, I’d like us to [vendor in eslint] (https://bugzilla.mozilla.org/show_bug.cgi?id=1491028) so that we can test these policies against something real as we continue to discuss and iterate on them.
This is NOT an exhaustive analysis of the various pros and cons of all the options available for using and handling node_modules. Whatever gets decided now, it’s all subject to reconsideration in the future, as we gain more experience with NodeJS and node_modules in mozilla-central.
In order to make it possible to have a high-level overview of the proposals, here is a table of contents into the policy doc with links:
High level proposal: we [vendor packages into /node_modules]
(https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.kfwtdxmvgnnh)
Vendoring Concerns/Proposed Policies:
* Proposed policy: node_modules currently for use at build-time only, to accelerate initial implementation. (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.1ymboxqoh497)
* Proposed policy: disallow modules with binary executables in mozilla-central except in critical cases to avoid differences between cross-platform builds and binary checkins. (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.ukei1hiusud0)
* License compatibility: choose a list similar to that used by `mach vendor rust`, vet with legal, automate (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.gfwanflj694p)
* Security/trust: landing time reviews, regular automated vulnerability scans (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.y6mzqzu3kg6u)
* Avoid importing tools with with their build-systems that don’t expose their build Directed Acyclic Graphs (i.e. the graph of all dependencies from inputs to outputs) (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.vn1vq8p5uod6)
* How to vendor in -- draft checklist (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.90qxauq1a5vs)
Node Engine concerns (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=id.tp8br5vz41jy)
* nodejs/npm version changes & security updates
* ability to build old versions (e.g. old ESR releases), given that node is coming from CI artifacts?