Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Npm Audit: broken by design?

overreacted.io

Post reply on HN
Print view View original

141–150 of 268 posts

Re: Npm Audit: broken by design?

#141

Post by username90 »

TechBro8615 wrote: post #127
gentleman11 wrote: post #43

npm is a bit nuts on its own. I started learning react this year and the course I'm taking had me install that create react app module or similar. It dragged in 1700 dependencies, and the folder for a hello world app was almost 90mb iirc. How can you possibly pretend you have any control over your app or it’s security in that situation?

The reason it’s so big is because it’s your build chain. I’ve always found this criticism of JS annoying – you’ve also got to pull in a few hundred MB of tooling for C++, Java, or Rust — it’s just that in the JS case, the “compiler” is usually per project.

Other libraries are usually self contained though, unlike JS libraries which contains dependencies and then those dependencies has dependencies etc. Probably has to do with JS lacking a standard library so it is a pain to do anything without including dependencies.

Re: Npm Audit: broken by design?

#142

Post by zerkten »

esens wrote: post #29

I found that much of the underlying cause is those mass reporting regex denial of services as being high severity bugs. So many people are reporting these in tons of different projects: https://github.com/search?q=regex+denial+of+service&type=iss... Anyhow it is just annoying and they broke NPM Audit based on these reports. It is good to fix all possible bugs, but many of these are not anywhere close to the level of…

Isn't this an area where gamification and machine learning could actually be useful, if applied carefully?

If people are competing for CVEs, then why not work out a way to better differentiate them them through scoring and make this visible. The goal would be for attention to shift to the scoring instead of only a CVE count. Offer both views of the world, so tools could still fall back on the problematic listings they get today.

Apply machine learning to classify CVEs based on the reputation of the reporter, blast radius, or other criteria. Use that to drive community review and scoring.

I would not see this a panacea because it brings a lot of challenges (a la StackOverflow), but it would be much better than what we have today.

Re: Npm Audit: broken by design?

#143

Post by cphoover »

enumjorge wrote: post #132
cphoover wrote: post #128

Earlier quoted context omitted.

> The threat model you're talking about neither seems realistic, nor like something npm audit can help with. The attack vector of a contributor sneaking in malicious code is dealt with by only giving the commit bit to trusted people, and reviewing code yourself. How is this not realistic when it has already been seen in the npm ecosystem multiple times. For an example of this in the wild see the event-stream (crypto-…

The problem is, if a security vulnerability snaked past the maintainers of a project, what hope do I have as someone who consumes the package to a) catch it b) know how to fix it?

That's exactly the issue that npm-audit seeks to ameliorate. It's not perfect, but it's better than nothing.

Re: Npm Audit: broken by design?

#144

Post by hsbauauvhabzb »

TechBro8615 wrote: post #127
gentleman11 wrote: post #43

npm is a bit nuts on its own. I started learning react this year and the course I'm taking had me install that create react app module or similar. It dragged in 1700 dependencies, and the folder for a hello world app was almost 90mb iirc. How can you possibly pretend you have any control over your app or it’s security in that situation?

The reason it’s so big is because it’s your build chain. I’ve always found this criticism of JS annoying – you’ve also got to pull in a few hundred MB of tooling for C++, Java, or Rust — it’s just that in the JS case, the “compiler” is usually per project.

That’s hardly true. Some standard libs are smaller, but in most other languages I can think of there isn’t the complete dependency hell. I want to install one package, the 50 dependencies or their ancestors create an audit he’ll (is the package secure, so I trust the developer to not inject malware, abandon the package, or add more dependencies), etc.

Re: Npm Audit: broken by design?

#145

Post by twistedpair »

JonathonW wrote: post #46
esens wrote: post #29

I found that much of the underlying cause is those mass reporting regex denial of services as being high severity bugs. So many people are reporting these in tons of different projects: https://github.com/search?q=regex+denial+of+service&type=iss... Anyhow it is just annoying and they broke NPM Audit based on these reports. It is good to fix all possible bugs, but many of these are not anywhere close to the level of…

A regex "denial of service" "vulnerability" could be important, if it shows up in code that processes untrusted input from end users. But NPM Audit has no idea of context-- a "critical" bug in `browserlist`, which, in this context, is never used outside the development process and never takes input outside of what's in my package.json, gets the same prominence (or more so, since it's early in alphabetical order) as a…

Would be nice if package.json had a flag to indicate the runtime would be either Node.js or a browser. So many of these "bugs" have no bearing in a browser context.

Re: Npm Audit: broken by design?

#146

Post by handrous »

tshaddox wrote: post #131
jrochkind1 wrote: post #65

> 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…

> That npm dependency trees are often insane doesn't help though. I'm not totally sure why they are so insane, but I increasingly think that npm's ability to have multiple versions of same dependency in the dependency tree -- often seen as a huge advantage over other platforms -- is in fact part of the problem. Aren't npm dependency trees so large because JavaScript doesn't have much of a standard library? And also,…

The lack of static typing (in base JS, at least) also makes it hard for tools to automatically spot very basic brokenness in dependencies without (repeatedly) running & testing the code. This makes even "safe" version bumps less trustworthy and harder to audit, and makes it harder for developers to notice if they've accidentally changed an interface on one of their libraries that they marked as a minor patch (i.e. the errors are both harder to check for, and more likely to occur, basically because they're harder to check for), so it's tempting to stick to old versions longer.

Add to that everything else—the fast pace of changes, javascript "culture", the weak standard library, the tendency to patch in what ought to either be basic language features or else avoided in favor of more-vanilla idioms, often in competing and incompatible ways—and all that is how you end up with 20 slightly-different copies of the same damn library in your dependency tree, and then 20 other copies of another library that does the same thing.

Re: Npm Audit: broken by design?

#147

Post by hsbauauvhabzb »

riho wrote: post #91

The the main problem is the fact that this audit happens with no context, and the audit results offer no information about the context an issue applies to either. Every issue should have a clear explanation about why and where it's an issue, and be tagged. Then we'd just need a way to hint npm what context a package will be used in, similarly to what we already do for devDependencies. Also going through an audit resu…

No it’s not. The main problem is the dependency tree hell. If an ancestor version bumps, you should probably version bump too, irrespective of exploitability.

Don’t like it? Try using more maintainable dependency trees.

Re: Npm Audit: broken by design?

#148

Post by twistedpair »

cratermoon wrote: post #34
esens wrote: post #29

I found that much of the underlying cause is those mass reporting regex denial of services as being high severity bugs. So many people are reporting these in tons of different projects: https://github.com/search?q=regex+denial+of+service&type=iss... Anyhow it is just annoying and they broke NPM Audit based on these reports. It is good to fix all possible bugs, but many of these are not anywhere close to the level of…

This kind of nonsense really goes back to the broken CVE process. https://opensourcesecurity.io/2021/03/30/its-time-to-fix-cve... Linux kernel maintainer Greg Kroah-Hartman has a similar opinion. https://github.com/gregkh/presentation-cve-is-dead/blob/mast... Edit: LWN mention https://lwn.net/Articles/801157/

I had a researcher contact me about a "vuln" in an OSS effort of mine once. The vuln made no sense w/ how the tool was used, but they published and I earned a CVE scarlet letter nonetheless. I finally "fixed" it, but IMHO, nothing was ever broken or vulnerable.

Re: Npm Audit: broken by design?

#149

Post by hsbauauvhabzb »

_fob_ wrote: post #36

Indeed, npm is not aware of the context of the vulnerabilities. That does not invalidate them, however, and mean they should be hidden. I've worked in offensive security for quite long enough (been a dev for 10+ years before) to tell you that your context, or the most common one, isn't all that exist and someone's going use it the way it makes the app vulnerable. Based on the article's example, someone's going to bui…

I agree.

Ever seen apps which are basically impossible to patch because devs have ignored patching for so long that it’s basically impossible to version bump things sanely? I have.

Re: Npm Audit: broken by design?

#150

Post by twistedpair »

jrochkind1 wrote: post #65

> 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…

> That npm dependency trees are often insane

For my hundreds of repos (Java, Scala, JS, Typescript, Python...), Snyk flags 99% of the CVEs for the JS repos. Shocking how I've only seen a few dozen or so Java based CVEs flagged over the last few years.

Perhaps it's because my NPM based repos have ~10K more dependencies? That and the Java stdlib handling most needs w/ the vanilla lang.

Post reply on HN