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

151–160 of 268 posts

Re: Npm Audit: broken by design?

#151

Post by eropple »

watwut wrote: post #78
eropple wrote: post #35

Earlier quoted context omitted.

> The other half is that many people reporting these issues have not "opted into" any security tooling and don't understand its tradeoffs. ... For a lot of people this is their first programming environment. This attitude makes me kind of uncomfortable. Like, I have taught software development to a decent number of folks, but I've always done so in a relatively isolated environment. If one is buying into web programm…

Frontend is however typical first place to develop in. And backend should never trust frontend anyway, making frontend actually lower risk place. You will hack yourself basically.

> Frontend is however typical first place to develop in

I think that, even today, this is a bold claim to make. Do you have something to substantiate it?

Re: Npm Audit: broken by design?

#152

Post by TechBro8615 »

hsbauauvhabzb wrote: post #144
TechBro8615 wrote: post #127

Earlier quoted context omitted.

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.

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 `tsc` or esbuild).

Re: Npm Audit: broken by design?

#153

Post by alerighi »

preinheimer wrote: post #58

Honestly, this hit me. I'm not a react developer, I was experimenting with it for a new project. I finished the tic-tac-toe tutorial, then tried to throw bootstrap on top to build from there. It told me there was 97 vulnerabilities (85 moderate, 12 high)... I just deleted the directory and went back to vanilla JS. This is a fun side project, I don't need that. My tweet about it: https://twitter.com/preinheimer/status…

That is exactly the point of the article. Every JS developer knows that these numbers are stupid and doesn't look at them.

However a beginner that doesn't know what impact they have of course is scared if when installing a library it tells you that there are all that vulnerabilities.

Re: Npm Audit: broken by design?

#155

Post by alerighi »

raziel2p wrote: post #16
mbesto wrote: post #13

> this “vulnerability” is absurd in this context Yes that's exactly the point. The audit tool has no awareness of the context and nor do the people who create severities. If severities were absolute then there would be no reason for anyone to review them. You would simply upgrade your libraries and be done with it, but that can't always be achieved nor may make business sense. I do agree with the author's note about…

Exactly. Why does it matter if it's absurd in this context? Just upgrade it to be on the safe side. Asking vulnerability databases to judge whether vulnerabilities are safe in devDependencies or not is a ridiculous idea, even more so when you consider that the line between static and dynamic have gone blurry long ago.

Have you ever worked with a complex project? Upgrading isn't easy if you have a moderate number of dependencies, also you risk introducing bugs for fixing a problem that really doesn't impact you. It doesn't make much sense to me...

Re: Npm Audit: broken by design?

#156

Post by gervwyk »

prionassembly wrote: post #83
esprehn wrote: post #30

Dan isn't the first person to notice: https://www.voitanos.io/blog/don-t-be-alarmed-by-vulnerabili... We disable [1] audit entirely because it's not a good default behavior within a monorepo. It spams the hundreds of developers with the list of "vulnerabilities" on every install, but only a few folks should really be upgrading packages. We then run audit in non-blocking CI and track the total number of issues and mos…

Having hundreds of developers work on the same code repository seems insanely complicated. What are the advantages? Where can I read more about monorepos?

We are just 2 devs at the moment and we've setup Lowdefy with a monorepo and yarn 2 and I can add that even for small projects a monorepo is just bliss especially with yarn 2 and lerna!

We come from separate repos on past versions of the code and the monorepo setup has sped dev up dramatically, even for a team of 2. Having the docs next to our code and autogen some of it from the source code, all is the same repo is just one advantage.

It's a small project but you can view the setup here: https://github.com/lowdefy/lowdefy

Re: Npm Audit: broken by design?

#157

Post by Angius »

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…

IMHO one solution would be to categorize vulnerabilities separately for prod dependencies and dev dependencies, and bubble that categorization up.

For example, a RegEx DDoS vulnerability in Express would show up as high severity, while the same would not show in the bundler you use, or any package that your bundler has in its dependency tree.

Re: Npm Audit: broken by design?

#158

Post by zelphirkalt »

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 matching groups and all that. In JS regex really feels horrible, even more cryptic than in other languages.

I think regexes are often used as a quick and dirty solution to problems, which should be solved differently. But once the regex "works" and is in place, others begin to rely on that output. Over time cruft begins to accumulate and the regex is forgotten or at least never replaced with anything more appropriate.

Re: Npm Audit: broken by design?

#159

Post by bhl »

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?

Just curious, have you tried vite with react? It uses esbuild, which might result in a heavier dependency folder, but I also wonder if getting rid of webpack removes a lot of the CRA dependencies.

Re: Npm Audit: broken by design?

#160

Post by ipaddr »

enumjorge wrote: post #136
munificent wrote: post #99

Earlier quoted context omitted.

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

You only support corporately funded open source?
Post reply on HN