111–120 of 268 posts
Or do commenters here actually believe that npm audit should treat a DoS of a development machine as a non-vulnerability?
(Please tell me it’s the former)
>> Unfortunately, there are hundreds.
This is primarily a result of the absurd number of dependencies NPM encourages (requires?) people to use. The duplicates are also there in part because of the large number of dependencies and should not be shown more than once by the tool.
Stop building projects with an absurdly large dependency tree, this is just one problem that results from it.
Earlier quoted context omitted.
Having hundreds of developers work on the same code repository seems insanely complicated. What are the advantages? Where can I read more about monorepos?
Google is probably the most (in?)famous example of monorepo. All of their code is in a single monorepo. You can read a bit about the approach’s benefits and drawbacks from someone at Google here: https://medium.com/@Jakeherringbone/you-too-can-love-the-mon...
> Inline all dependencies during publish… From a maintainer’s point of view, the upsides are clear: you get faster boot time, smaller downloads, and — as a nice bonus — no bogus vulnerability reports from your users. And when you inlined a version that later really does have a vulnerability, it is not easily flagged or fixed by your consumers. The tension between "upgrades (especially of indirect dependencies) might…
Well said. I would add that I think the devDependencies solution is underrated. Not using it is a bad practice. npm has a nice feature, `npm prune --production` which will remove all the dev dependencies for you resulting in a clean build of the program. You can easily have things set up so that none of the development dependencies that have all these audit issues are ever present on your production machines if you d…
Earlier quoted context omitted.
> Just upgrade it to be on the safe side Upgrading a dependency can go anywhere from trivial to absolute nightmare. Usually somewhere in the middle where it takes time and effort to do right. A typical JS app nowadays has hundreds if not thousands of dependencies. I'd love to see a world where "just upgrade" is reasonable advice, but we are not there.
Or even undoable because it is a dependency of dependency, that vulnerable major version is no longer maintained, and your dependency heavily relies on specific feature of that major version. At this point, what should you do now? The author of dependency of dependency is probably not going to touch it because it is fixed in the new major version. The author of dependency is probably also not going to fix it instantl…
Yes, you now don't get vuln. notifications for the original repo, which is an issue in itself. It would be nice to mark a CVE as mitigated in your package.json and to also mark a resolution to still pick up CVEs from the original package. E.g
{
"dependencies": {
badRepo: "1.0.0" // has a dependency that is vulnerable
},
"resolutions": {
"badRepo/**/dependency": "git://github.com/org/dependency" // fixed, but now won't report new cves from the original badRepo/**/dependency package. Would be good to specify that we still want reports for the original repo
That is how we handle such issues in our team, we also review any forks at the start of every sprint to see if it has been resolved and we can remove the fork dependency.
If the vuln is valid and exploitable in your system, what other choice do you have? It's the pitfalls on depending on 3rd party packages. If you are using an old major version that now has a vuln that is only fixed in a newer version, NPM doesn't make that situation worse.
Caveat: These are my 5 minutes thoughts, I could probably do a better, more thorough write up.
Earlier quoted context omitted.
I see your point that even worse things can happen when dev machines are compromised. The point I tried to make is that even a DoS of your machine can be a big problem. > There is nothing any attacker can do with the static files on the server that will trigger a RegEx DoS... IIUC, an attacker could change my package.json to include inputs to browserlist that trigger a RegEx DoS. To do that, the attacker only needs t…
If you, as an attacker, are going to make a fraudulent commit and change package.json, you could just pull in a bogus dependency or add a new script/command that gets run on the build/dev machine. I agree the bar to submitting a fraudulent commit is unfortunately too low for many teams. But, this also extends to package publishing, too. We've seen packages published through compromised dev keys or the maintainer gran…
Are we shooting the messenger (npm audit) here? Seems like the problem is lack of trust and lack of information about security of dependencies. Npm audit is just pointing that out. The size of the problem makes it very uncomfortable.
Earlier quoted context omitted.
Google is probably the most (in?)famous example of monorepo. All of their code is in a single monorepo. You can read a bit about the approach’s benefits and drawbacks from someone at Google here: https://medium.com/@Jakeherringbone/you-too-can-love-the-mon...
Does monorepo mean that if I checkout Google Wave, I also checkout the GMail source too?
Once you have the tooling to do this you can use the monorepo to store all kinds of interesting things, like built artifacts or the contents of the CDN, since it's basically just a giant hierarchical KV store with a global version.
Earlier quoted context omitted.
Google is probably the most (in?)famous example of monorepo. All of their code is in a single monorepo. You can read a bit about the approach’s benefits and drawbacks from someone at Google here: https://medium.com/@Jakeherringbone/you-too-can-love-the-mon...
Does monorepo mean that if I checkout Google Wave, I also checkout the GMail source too?
https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...