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

131–140 of 268 posts

Re: Npm Audit: broken by design?

#131

Post by tshaddox »

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, similarly, the community is so large and has been moving so fast that even de facto standards have difficulty forming and surviving at a large scale across the community.

Re: Npm Audit: broken by design?

#132

Post by enumjorge »

cphoover wrote: post #128
TheDong wrote: post #100

Earlier quoted context omitted.

> what if one of your contributors slips in a merge that uses the vulnerable code path of your dependency If your threat model is a contributor submitting malicious code, your problem is not something npm audit will help with either way. If a malicious actor is able to add the "not affected" marker, you have bigger problems. The threat model you're talking about neither seems realistic, nor like something npm audit c…

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

Re: Npm Audit: broken by design?

#133

Post by zkldi »

quintex wrote: post #6

As someone who only had just gotten into front end programming after years of backend work, npm has been a nightmare. I haven't experienced the same level of frustration with other package managers (pip, cargo, go mod, etc) as I have with npm. Is yarn the better option? What is our path forward?

PNPM[1] has became a must-use for me in every node project I work on now.

[1]: https://pnpm.io/

Re: Npm Audit: broken by design?

#134

Post by thomascgalvin »

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…

We got bit by this last week; our scans were suddenly all red, and nobody could deploy to production. We had to write an analysis of why this wasn't actually dangerous to us in order to get security to suppress the findings.

Re: Npm Audit: broken by design?

#135

Post by apayan »

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/

Here's the video of the talk that goes with Greg Kroah-Hartman's slides: https://www.youtube.com/watch?v=HeeoTE9jLjM

Re: Npm Audit: broken by design?

#136

Post by enumjorge »

munificent wrote: post #99
theptip wrote: post #85

Earlier quoted context omitted.

> I'm not totally sure why they are so insane I think a big part of it is that due to much stronger pressure on bundle size than most other environments, each library tends to be small, so there have to be more to carry the same amount of functionality. Duplicates are certainly a contributing factor as well, and small bundles compound with allowed-duplication to further increase the tree size. I think that small pack…

I agree with all of this. Also JavaScript's "standard library" is nearly nonexistent (or at least was when Node first got big). That built a culture of people assuming they needed to reach for third-party dependencies for nearly everything (see: leftpad).

Slightly related to the lack of a standard library is that a lot of these 3rd party packages come from random people in the community. It’s great that people are so willing and able to share code, but it also means that as a community we put a lot of trust into code that may not be vetted or funded properly. I think we assume that because these packages are open source that someone is making sure they are safe to consume, but because there’s so many of them it’s hard to verify them.

Re: Npm Audit: broken by design?

#137

Post by junon »

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…

I'm a maintainer of a few of the larger packages on npm. This is generally pretty accurate. Snyk Security seems only to find regex DoS bugs and I'm a bit disappointed in them being classified as high severity, and they're the only ones submitting reports right now.

They seem pretty adamant on filing CVEs despite what the owner says (It's normally fine but these DoS vulns require very large input to be handed into the function by untrusted sources, which given how these libraries work isn't going to be very common).

Now, I have people yelling at me about dependent packages not being updated because they don't understand version ranges, or because some audit states they are high vulns, or whatever.

Super broken, everything related to npm's package lock stuff is broken by design. I've been saying it for years now and it seems people still cling to blindly trusting what corporations say.

Re: Npm Audit: broken by design?

#138

Post by BeFlatXIII »

cratermoon wrote: post #55
zinekeller wrote: post #44

Earlier quoted context omitted.

The view of SQLite developers on CVEs is also dim: https://www.sqlite.org/cves.html

Beautifully succinct. This quote: "Grey-hat hackers are rewarded based on the number and severity of CVEs that they write. This results in a proliferation of CVEs that have minor impact, or no impact at all, but which make exaggerated impact claims." Alignment of incentives is messed up. Goodhart-Strathern's and Campbell's laws apply.

Sounds like academic research publications. Sure, that will totally be a key step toward cancer therapy or better biofuels (realistically, the PI gets his jollies by shoving aldehyde groups onto random molecules)

Re: Npm Audit: broken by design?

#139

Post by px43 »

G3rn0ti wrote: post #76
cratermoon wrote: post #55

Earlier quoted context omitted.

Beautifully succinct. This quote: "Grey-hat hackers are rewarded based on the number and severity of CVEs that they write. This results in a proliferation of CVEs that have minor impact, or no impact at all, but which make exaggerated impact claims." Alignment of incentives is messed up. Goodhart-Strathern's and Campbell's laws apply.

Maybe then writing and submitting a CVE should cost some money that’s payed back together with the reward if the vulnerability is found to be „reasonable“ upon review?

Believe me, 90% of people who find bugs for a living are perfectly content with keeping them to themselves and/or selling them privately.

Re: Npm Audit: broken by design?

#140

Post by scottlamb »

trunnell wrote: post #111

How much of the problem here is that npm audit is a little annoying and creates problems unrelated to security? 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)

> Or do commenters here actually believe that npm audit should treat a DoS of a development machine as a non-vulnerability?

I believe that npm audit should treat a DoS of a development machine by a trusted developer as a non-vulnerability. "Code I (or a fellow committer) wrote uses a lot of CPU" isn't a vulnerability. If I care to prevent this, I should run said code within a cgroup with limited resources, not panic about theoretical expense in one part of the codebase while necessarily allowing arbitrary execution elsewhere. "npm audit" is crying wolf, just as the author said.

I like the proposal [1] near the end: "If I own an npm package I need to be able to tag a certain transitive vulnerability category as not affecting my usage of that transitive package." This is particularly important for npm given things like create-react-app but would also be a good idea for "cargo audit" and such.

[1] https://twitter.com/dan_abramov/status/1412380714012594178

Post reply on HN