[vemv]

Even a specific dependency can sneak malicious code.

For example foo-2.3.1 when distributed over npm is not guaranteed to match its source over github.

Here's a popular piece explaining various plausible scenarios https://medium.com/hackernoon/im-harvesting-credit-card-numb...

(npm is not different from cocoapods I guess... except that npm dependency trees are famed for its size/depth)

[danShumway]

Evergreen reminder that with just a little bit of work to avoid platform-specific native-compiled dependencies and Node-Gyp, you can vendor your dependencies for non-library Node projects, and sometimes you should.

Certainly, Electron apps themselves should not be pulling dependencies at install time, those should be bundled into the app, that's the whole point of Electron. But they also don't need to pull their dependencies from the official NPM repos at build time either. You don't technically even need NPM installed on anything other than your dev machines, Node's dependency resolution during builds and at runtime doesn't rely on NPM at all.

I think some languages (Go springs to mind) are starting to slightly popularize dependency vendoring more, and at one point this was the official recommendation for Node apps/websites in the official docs. It fell out of fashion for some reason, but I think a lot of orgs would benefit from picking up the practice again.

It's also a good way to be a lot more deliberate about what you install, and a good way to make sure that new dependencies don't get snuck in without anyone noticing. It's very hard to hide a giant commit that introduces a thousand new files, and that can sometimes be a good opportunity to take a step back and ask yourself why you're adding a dependency that introduces thousands of files.

[jart]

Check out Cosmopolitan which vendors all its dependencies. https://github.com/jart/cosmopolitan You can't use Node with it, yet, but you can use QuickJS if you `make o//third_party/quickjs/qjs.com` and `o/third_party/quickjs/qjs.com -m third_party/quickjs/repl.js`. Cosmopolitan goes so far with vendoring dependencies that it actually has its own C library implementation that prevents functions like socket(), connect(), and getaddrinfo() from talking to the Internet if the software is running under GNU Make. Since sometimes we've found when porting software it'll have unit tests that do sneak leaks to public servers. It goes without saying that in order to make it even possible to vendor all dependencies, down to the binary level, there's a very long list of topologically ordered things that need to happen before you can even talk to the Internet. https://github.com/jart/cosmopolitan/blob/50937be7524197f23a... It's all cross platform and native at the same time for CLI/TUI. It'd surely make a more trustworthy tooling stack for a password manager than something like Electron since the temptation for people to incorporate things like FullStory into such GUIs is too great.

[yunohn]

That’s not how electron works - it bundles dependencies. Like any other app bundle (exe, msi, dmg). Same goes for non-electron websites (/apps).

I guess there’s a way to also auto-update those, but that defeats the goal of using Electron - reproducible, predictable app builds to ship to consumers.