Intent to require Node to build Firefox 61 and later

[Nicholas Alexander]

Hello dev-platform,

For the reasons outlined at https://docs.google.com/document/d/1tOA2aeyjT93OoMv5tUMhAPOkf4rF_IJIHCAoJlwmDHI/edit?usp=sharing, we would like to make Node a requirement to build Firefox sometime in the Firefox 61 development cycle. (Firefox 60 will be an ESR release, so this provides a complete ESR cycle without requiring Node.)

The requirement will likely be Node v8.9.4, the current LTS release.

I would like feedback -- positive and negative -- from downstream packagers, users of various operating systems and distributions, and interested developers about this proposal.  There has already been some discussion on dev-builds: https://groups.google.com/d/msg/mozilla.dev.builds/L2Tp2uS1PGE/yiy30e1EAgAJ.

Please comment on the Google Doc linked above (everybody with the link should be able to comment), or reply with comments on dev-b...@lists.mozilla.org.

Thanks!

Nick

[Peter Saint-Andre]

On 2/28/18 5:23 PM, Nicholas Alexander wrote:
> Hello dev-platform,
>
> For the reasons outlined at
> https://docs.google.com/document/d/1tOA2aeyjT93OoMv5tUMhAPOkf4rF_IJIHCAoJlwmDHI/edit?usp=sharing,

It would be good to document the security implications of this approach.
By using Node we will probably inherit a large number of third-party
dependencies. Although we could use a service such as the Node Security
Platform [1] to determine the security status of these dependencies,
regular monitoring and upgrading will be needed to ensure that we do not
introduce vulnerabilities into our build process.

Thanks for listening. :-)

Peter

[1] https://nodesecurity.io/

[Nicholas Alexander]

Hi Peter, others,

This is an excellent point, and I will add a section into the "Intent to require Node to build Firefox 61" document discussing it.

There is a separate but related sibling proposal that has not yet left a small working group that aims to make vendoring into mozilla-central more uniform and more automated.  That proposal directly addresses the security story around vendored third-party dependencies and their transitive dependencies -- in fact, it's a motivating force behind that proposal.  We (folks behind the Node proposal) are actively working with the folks behind this sibling proposal to ensure that we have a workable solution to upgrading Node dependencies across the tree in a timely manner in the face of security updates.

Thanks for sharing the nodesecurity.io service -- I'll read more as I add the section.

Yours,

Nick

[Boris Zbarsky]

On 3/6/18 5:36 PM, Nicholas Alexander wrote:
> We (folks behind the Node proposal) are actively working with
> the folks behind this sibling proposal to ensure that we have a workable
> solution to upgrading Node dependencies across the tree in a timely
> manner in the face of security updates.

Note that it's not just about making sure we take security updates as
they become available. It's also about _not_ taking updates to packages
in situations where the package ownership (for the same name) changes,
etc....

-Boris

[Peter Saint-Andre]

On 3/6/18 3:36 PM, Nicholas Alexander wrote:
> Hi Peter, others,
>
> On Tue, Mar 6, 2018 at 1:13 PM, Peter Saint-Andre <stp...@mozilla.com
> <mailto:stp...@mozilla.com>> wrote:
>
> On 2/28/18 5:23 PM, Nicholas Alexander wrote:
> > Hello dev-platform,
> >
> > For the reasons outlined at
> > https://docs.google.com/document/d/1tOA2aeyjT93OoMv5tUMhAPOkf4rF_IJIHCAoJlwmDHI/edit?usp=sharing

> <https://docs.google.com/document/d/1tOA2aeyjT93OoMv5tUMhAPOkf4rF_IJIHCAoJlwmDHI/edit?usp=sharing>,

>
> It would be good to document the security implications of this approach.
> By using Node we will probably inherit a large number of third-party
> dependencies. Although we could use a service such as the Node Security
> Platform [1] to determine the security status of these dependencies,
> regular monitoring and upgrading will be needed to ensure that we do not
> introduce vulnerabilities into our build process.
>
>
> This is an excellent point, and I will add a section into the "Intent to
> require Node to build Firefox 61" document discussing it.

Great.

> There is a separate but related sibling proposal that has not yet left a
> small working group that aims to make vendoring into mozilla-central
> more uniform and more automated.  That proposal directly addresses the
> security story around vendored third-party dependencies and their
> transitive dependencies -- in fact, it's a motivating force behind that

> proposal.  We (folks behind the Node proposal) are actively working with

> the folks behind this sibling proposal to ensure that we have a workable
> solution to upgrading Node dependencies across the tree in a timely
> manner in the face of security updates.

Looking forward to hearing more.

> Thanks for sharing the nodesecurity.io <http://nodesecurity.io> service

> -- I'll read more as I add the section.

There a few other services like that (e.g., Snyk, SourceClear), I just
happen to know NSP best because I've used it at previous companies.

Peter