Straw man mozilla-central node_modules policies; comments requested

[For those who have seen earlier iterations of this document, the security =
section now discusses the recent event-stream/flatmap-stream exploit specif=
ically --dmose]

I=E2=80=99ve drafted a set of straw man proposals for getting basic node_mo=
dules 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 f=
or teams/maintainers who want to improve their efficiency.  In this context=
, =E2=80=9Cvendor=E2=80=9D is being used to mean =E2=80=9Creview, land, and=
 maintain 3rd party software packages=E2=80=9D in mozilla-central.

Once it=E2=80=99s clear that we have rough agreement about the linked polic=
ies (i.e. no major objections for a week after publishing to firefox-dev an=
d dev-platform), I=E2=80=99d like us to [vendor in eslint] (https://bugzill=
a.mozilla.org/show_bug.cgi?id=3D1491028) 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 decid=
ed now, it=E2=80=99s all subject to reconsideration in the future, as we ga=
in 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-eHW8jYazq3jSno52wd=
zXGxg/edit#bookmark=3Did.kfwtdxmvgnnh)

Vendoring Concerns/Proposed Policies:

* Proposed policy: node_modules currently for use at build-time only, to ac=
celerate initial implementation. (https://docs.google.com/document/d/1ORWbl=
USfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=3Did.1ymboxqoh497)

* Proposed policy: disallow modules with binary executables in mozilla-cent=
ral except in critical cases to avoid differences between cross-platform bu=
ilds and binary checkins. (https://docs.google.com/document/d/1ORWblUSfmbV9=
R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=3Did.ukei1hiusud0)

* License compatibility: choose a list similar to that used by `mach vendor=
 rust`, vet with legal, automate (https://docs.google.com/document/d/1ORWbl=
USfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=3Did.gfwanflj694p)

* Security/trust: landing time reviews, regular automated vulnerability sca=
ns (https://docs.google.com/document/d/1ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno5=
2wdzXGxg/edit#bookmark=3Did.y6mzqzu3kg6u)

* Avoid importing tools with with their build-systems that don=E2=80=99t ex=
pose their build Directed Acyclic Graphs (i.e. the graph of all dependencie=
s from inputs to outputs) (https://docs.google.com/document/d/1ORWblUSfmbV9=
R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=3Did.vn1vq8p5uod6)

* How to vendor in -- draft checklist (https://docs.google.com/document/d/1=
ORWblUSfmbV9R75LGoq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=3Did.90qxauq1a5vs=
)

Node Engine concerns (https://docs.google.com/document/d/1ORWblUSfmbV9R75LG=
oq-eHW8jYazq3jSno52wdzXGxg/edit#bookmark=3Did.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?
0
dmosedale
11/29/2018 9:07:17 PM
mozilla.dev.builds 1723 articles. 0 followers. Post Follow

1 Replies
13 Views

Similar Articles

[PageSpeed] 54

On Thursday, November 29, 2018 at 1:07:18 PM UTC-8, dmos...@mozilla.com wro=
te:
>
> Once it=E2=80=99s clear that we have rough agreement about the linked pol=
icies (i.e. no major objections for a week after publishing to firefox-dev =
and dev-platform), I=E2=80=99d like us to [vendor in eslint] (https://bugzi=
lla.mozilla.org/show_bug.cgi?id=3D1491028) so that we can test these polici=
es against something real as we continue to discuss and iterate on them.

Given that we'll all be very busy this coming week, I don't think the 1 wee=
k deadline actually makes sense, and I suspect we'll actually want to have =
at least some of the security scan automation up and running first.  So don=
't worry about the above timing.  :-)

Dan
0
dmosedale
11/29/2018 9:25:22 PM
Reply: