Straw man mozilla-central node_modules policies; comments requested

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Straw man mozilla-central node_modules policies; comments requested

Dan Mosedale-4
[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.e. no major objections for a week after publishing to firefox-dev and dev-platform), 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?
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Straw man mozilla-central node_modules policies; comments requested

Dan Mosedale-4
On Thursday, November 29, 2018 at 1:07:18 PM UTC-8, [hidden email] wrote:
>
> Once it’s clear that we have rough agreement about the linked policies (i.e. no major objections for a week after publishing to firefox-dev and dev-platform), 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.

Given that we'll all be very busy this coming week, I don't think the 1 week 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
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds