1588517 - Use lockfile-lint as an automatic check for the projects who use npm and yarn

Status: NEW

(DevTools :: General, task, P3)

Description

[Julien Wajsberg [:julienw]]

Over the week-end, I read this interesting article about using our lockfiles (either yarn.lock for yarn or package-lock.json for npm) as attack vectors. This is taking advantage on the fact that repository owners do not carefully check changes to the lockfiles because that's tedious and usually handled by tools.

The article proposes to use lockfile-lint to check for common threats. The tool isn't perfect but can already check for some obvious unexpected stuff. I suggest that panels that use yarn/npm to manage dependencies and use lockfiles (that means end projects, not so much for libraries) use that. This is especially important for us because our code ends up in Firefox and runs with privileges.

This is how I implemented it for the profiler.

Comment 1

[Alexandre Poirot [:ochameau]]

(In reply to Julien Wajsberg [:julienw] from comment #0)

Over the week-end, I read this interesting article about using our lockfiles (either yarn.lock for yarn or package-lock.json for npm) as attack vectors. This is taking advantage on the fact that repository owners do not carefully check changes to the lockfiles because that's tedious and usually handled by tools.

This is especially important for us because our code ends up in Firefox and runs with privileges.

I may be wrong here, but I don't think any node/npm/yarn module ships into Firefox from /devtools folder.
My current comprehension of node usage within DevTools is that it is only used to build and test things, but isn't used in the final production code.

Now. There may still be value in spotting malicious code running from our CI...

Comment 2

[Julien Wajsberg [:julienw]]

it is only used to build

=> and so, what does it mean if we get malicious dependencies that inject code in the building phase ?

I'm not very aware of the current state of things within devtools. But if we depend on yarn.lock or package-lock.json to run things on shipped code, or if we ship compiled bundles directly in Firefox, then it can be a problem.

Comment 3

[Julian Descottes [:jdescottes]]

I assume that all the panels that use npm/yarn only for running tests (application panel, accessibility, aboutdebugging, console, netmonitor) should not be impacted. Nothing from the node world impacts any code that ships with Firefox for those panels.

However for the debugger, I believe we still rely on npm packages in order to build (bundle & transpile) files that will be shipped with Firefox. Let's ni? Jason to get some feedback from the debugger side of things.

Comment 4

[Jason Laster [:jlast]]

None of the code from node_modules ends up in firefox.

I agree that lockfile-lint is a good idea.

CC Dan Mosedale

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

I agree that this is a fine idea. In fact, I'd like to build it in to mach vendor node so that it always runs at the top-level. This wouldn't address stuff in package.json files in other subdirs, however. Is it OK if I scope down this bug for that, or would you prefer that I file a separate bug?