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

181–190 of 268 posts

Re: Npm Audit: broken by design?

#181

Post by zelphirkalt »

tshaddox wrote: post #177
zelphirkalt wrote: post #171

Earlier quoted context omitted.

You and GP have shown me new even more scary depths here. Not sure whether I should thank you for that. (When does the next flight off this rock go?)

It's not really that crazy. This package is a small amount of code, but it's important code (the same goes for this package's dependency is-number). This package shows up in the dependency trees of some popular packages, which is probably where most of the weekly downloads come from. If you're writing straightforward application code where you already know you have a valid number, then this package probably isn't for…

I get it, JS is a weird language, but simple things like "is number" are still easy enough to do in JS, especially, when ints and floats are all just "number" in JS:

function is_number(val) { return typeof val === "number"; }

With a function that easily written, no one should have any excuse to depend on a third-party dependency for it.

Re: Npm Audit: broken by design?

#182

Post by LadyCailin »

tshaddox wrote: post #177
zelphirkalt wrote: post #171

Earlier quoted context omitted.

You and GP have shown me new even more scary depths here. Not sure whether I should thank you for that. (When does the next flight off this rock go?)

It's not really that crazy. This package is a small amount of code, but it's important code (the same goes for this package's dependency is-number). This package shows up in the dependency trees of some popular packages, which is probably where most of the weekly downloads come from. If you're writing straightforward application code where you already know you have a valid number, then this package probably isn't for…

leftpad was a small amount of code too. If it’s a small amount of code that’s design stable and downloaded often, it’s an extremely strong candidate for inclusion in the standard library.

Re: Npm Audit: broken by design?

#183

Post by Touche »

efitz wrote: post #175

Writing my comments in the snarky tone of the article. So the article boils down to “a bunch of these vulnerabilities aren’t applicable to my app which is built using a specific NPM package”. Congratulations. Welcome to the world of practical information security. As a security engineer, we’re lucky if your favorite package manager even associates vulnerability information with your packages. Never mind that you’re p…

Typical security engineer opinion. This "feature" is costing the industry tens, perhaps hundreds of million of dollars in wasted salary hours but it's worth it to you in the off-chance .1% are even potentially affected. Because only your job matters.

Re: Npm Audit: broken by design?

#184

Post by sqrt17 »

zelphirkalt wrote: post #158
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…

The more I work with parsing, parser combinators and writing grammars for little languages, the less often I find myself using or wanting to use any regex at all. When I do, I always feel like there should be a better way, perhaps a type safe way of accessing the info I need and so on. It feels "Ugh, there should be a better way to do this." Especially in JavaScript, regexes blow in comparison to languages with named…

> The more I work with parsing, parser combinators and writing grammars for little languages, the less often I find myself using or wanting to use any regex at all.

Surprise: The most common parser combinator libraries do backtracking. That's exactly the problem. Any solution as widely used (if not overused) as regular expressions ends up exposing a number of dark corners where the design isn't as clean and tight as you would want it. There are lots of better ways, but most of them are specialized and are totally unsuited for significant areas where people need something.

That said: yes I've used LR(1) parsing (not LALR) using a library that uses parser combinators with a good interface, and it's more powerful than regex and worth it for the right usecase.

Re: Npm Audit: broken by design?

#185

Post by tshaddox »

zelphirkalt wrote: post #181
tshaddox wrote: post #177

Earlier quoted context omitted.

It's not really that crazy. This package is a small amount of code, but it's important code (the same goes for this package's dependency is-number). This package shows up in the dependency trees of some popular packages, which is probably where most of the weekly downloads come from. If you're writing straightforward application code where you already know you have a valid number, then this package probably isn't for…

I get it, JS is a weird language, but simple things like "is number" are still easy enough to do in JS, especially, when ints and floats are all just "number" in JS: function is_number(val) { return typeof val === "number"; } With a function that easily written, no one should have any excuse to depend on a third-party dependency for it.

But the code you posted is not what the code in this package does. If all you need is the code that you posted, then you should absolutely use that.

Re: Npm Audit: broken by design?

#186

Post by IggleSniggle »

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…

Agreed!

A “Critical” bug in a dev context should mean something very different from a “Critical” bug in a prod context. A “Critical” devDependency bug should be either a direct threat to the developer’s context, either by infecting the dev machine or by injecting a supply-chain problem, worming it’s way into downstream contexts.

npm audit is just not granular OR careful enough to address these issues appropriately.

Re: Npm Audit: broken by design?

#187

Post by [deleted] »

twistedpair wrote: post #145
JonathonW wrote: post #46

Earlier quoted context omitted.

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.

[deleted]

Re: Npm Audit: broken by design?

#188

Post by DaiPlusPlus »

jrockway wrote: post #174
twistedpair wrote: post #148

Earlier quoted context omitted.

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.

I wouldn't call a CVE a scarlet letter. Given the current state of software engineering, it's more like "my project is valuable enough to be used by someone that cares about security". You fixed it, one less bug to worry about. No doubt there are many less popular products with many worse vulnerabilities that don't have a CVE. Even OpenBSD had to change their tagline to "Only two remote holes in the default install,…

> You fixed it, one less bug to worry about.

Those "bugs" can be features though - or the work involved to fix the bug meant that high-impact feature work - or other bugfixes, had to be postponed or even cancelled.

Our SaaS frequently gets security "researchers" (read: people running online scanners) submitting emails through our contact-form informing us about click-jacking attacks on our login-page - the problem for us is that we have a lot of second-party and third-party integrations on unbounded origins that offer access to our application, and by extension our login-screen through an on their own origin, which is sometimes even an on-prem LAN web-server accessed through embedded devices where we can't use popups to do it properly - let alone switch to a more robust OIDC system - so there is no easy solution that makes the "I ran a tool, gimme $100" people go-away without causing a much bigger problem to now exist.

Re: Npm Audit: broken by design?

#189

Post by argomo »

cphoover wrote: post #41
danabramov wrote: post #14

Earlier quoted context omitted.

> I'm not sure the author's point, that development configuration could not hide malicious code? Why not? Quite the opposite! Quoting the article: As any security professional will tell you, development dependencies actually are an attack vector, and perhaps one of the most dangerous ones because it’s so hard to detect and the code runs with high trust assumptions. This is why the situation is so bad in particular: a…

All it does is look to see if either your direct dependencies or descendant dependencies exist in the advisory database.... It seems like a simple algorithm that works pretty well. Perhaps ignoring certain dependencies makes sense, via an ignore list. I just find the title "NPM is broken by design" to be a little hyperbolic, when it seems like the complaint is that it's tedious removing all the low-quality dependenci…

Think of the article as customer feedback. The customer may not appreciate everything the product does for them, nor may they be using it in the fashion where it would be most effective.

So what? Your job (if this was your customer) would be to figure out how to make them happier. Maybe you are getting down-voted because (while you're correct on some fine points), you're broadly dismissing the concerns of the article. Case in point: those "low-quality dependencies" aren't something you can easily switch out for quality parts... they're deep dependencies of many of npm's flagship tools and frameworks.

Re: Npm Audit: broken by design?

#190

Post by hsbauauvhabzb »

TechBro8615 wrote: post #152
hsbauauvhabzb wrote: post #144

Earlier quoted context omitted.

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.

My point was that if you're comparing JS dependencies to other languages, you need to include their compilers too, since e.g. TypeScript projects depend on `tsc`. If you include the size of C/C++/Rust/Java/etc. compilers, I'm sure you'll find 50mb+ of dependencies. You're right that it's self-contained though (to be fair, so is `tsc` – most projects could shed a lot of dependencies by abandoning Babel in favor of `ts…

Sure but gcc, clang and python have had a substantial amount of review. There’s no assurance that similar occurs in the non ecosystem.
Post reply on HN