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

121–130 of 268 posts

Re: Npm Audit: broken by design?

#121

Post by j1elo »

I guess we could have a documentary series!

Next up, npm link: broken by design

Synopsis of the chapter: A command with broken behavior that has been reported since as early as 2015, but that "got lost" every time the winds changed and the project decided to change where to manage bugs. What will happen in the latest attempt from an affected user? Tune in and be ready for an exciting ride!

https://github.com/npm/cli/issues/2372

Spoiler: bugs are not sentient beings that solve themselves just by closing the issue (or the whole issue tracker, for that matter).

EDIT to clarify: Sorry for the snarkyness. I just find it funny in a sarcastic way that up until I reported the issue in 2020, the issue had been reported repeatedly but "lost" in the way because the project closed or ignored the issue every time it changed issue tracker. Which happened twice since 2017! so go figure the amount of reports that had gone to waste. On the flip side, this time they haven't changed platforms (yet), although the issue has been closed prematurely anyway.

Re: Npm Audit: broken by design?

#122

Post by suhas_rd »

x86_64Ubuntu wrote: post #114
SOLAR_FIELDS wrote: post #105

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?

yes

Re: Npm Audit: broken by design?

#124

Post by TechBro8615 »

phkahler wrote: post #113

>> Five false alarms wouldn’t be too bad. >> 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…

I’d imagine that in most projects, the bulk of the dependency is due to dev tooling. I don’t think it’s fair to optimize for small dependency trees when setting up your buildchain – otherwise you’re precluding any usage of create-react-app or Next or whatever development platform. This problem is further compounded by the fact that those tools encourage including dev dependencies as regular dependencies, since the output is compiled anyway.

The answer here is probably some kind of static analysis to know which packages end up shipping in the actual bundle to users. I think Dan referenced some work in that regard.

Re: Npm Audit: broken by design?

#125

Post by mulcahey »

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?

Monorepos are pretty common nowadays, arguably popularized by Google

https://research.google/pubs/pub45424/

That said (1) “you are not Google” as the saying goes (2) Google built their VCS from scratch in house for scale.

However it’s not tops hard to do this with just git and some rules/patterns for organization.

Re: Npm Audit: broken by design?

#126

Post by cratermoon »

smsm42 wrote: post #96
G3rn0ti wrote: post #76

Earlier quoted context omitted.

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?

AFAIK MITRE has a process for an organization to register as vendor, and then it would accept CVEs for their products only from the vendor, not from random people. Of course this has an opposite failure mode that may have unscrupulous vendors hide issues or just be lazy in issuing CVEs for existing bugs, but it eliminates the problem of random people issuing a ton of CVEs for non-issue bugs.

I'm pretty sure CVEs and the like came about because vendors were choosing to hide or deny security vulnerabilities. Vulnerability disclosure policies are a whole different kettle of worms.

Re: Npm Audit: broken by design?

#127

Post by TechBro8615 »

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.

Re: Npm Audit: broken by design?

#128

Post by cphoover »

TheDong wrote: post #100
cphoover wrote: post #72

Earlier quoted context omitted.

> Because as the package owner I _do_ have that context. I understand there may be significant issues with this approach though! But what if one of your contributors slips in a merge that uses the vulnerable code path of your dependency... Does this "not affected" marker still exist, and now you have vulnerable code? Does it disappear with each version? What if someone maliciously adds a "not affected" marker? To a p…

> 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-mining trojan) fiasco: https://github.com/dominictarr/event-stream/issues/116

Dependencies are a target for exploit, your package may be safe now and then become unsafe in the future, either intentionally or unintentionally.

Re: Npm Audit: broken by design?

#129

Post by x0x0 »

dane-pgp wrote: post #106
x0x0 wrote: post #64

Earlier quoted context omitted.

We also wanted to use npm audit in our CI process so, instead of humans being careful, we could assert any known CVE stops a staging or prod deploy. Very annoyingly, npm audit doesn't have ignore functionality, at least when I was last forced to use it. I had to hack something together with bash scripts. For vulnerabilities that we determined weren't an issue ever (vuln in frontend framework we didn't use), or weren'…

> Very annoyingly, npm audit doesn't have ignore functionality I can't believe no one here has mentioned the fantastic tool "better-npm-audit" which can be included as an npm dependency[0] and lets you add specific vulnerabilities to an ignore list. The ignore list is actually a JSON config file stored alongside package.json in the repo, so only one developer ever needs to see the npm audit warning and can mute it fo…

Thank you!

edit: we're going to move to this. My implementation is a is a file with cve to ignore | reason | jira ticket but I think we can slam all that in there. And our expiry is manually checked monthly, so this is a big improvement.

Re: Npm Audit: broken by design?

#130

Post by Avamander »

nkozyra wrote: post #59
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…

> A regex "denial of service" "vulnerability" could be important, if it shows up in code that processes untrusted input from end users. But in this context what's the end result? Chrome locking up on the end user's (attacker's) machine? Again, an "attacker" doesn't have access to the source code for distribution. By inputting bad regexp data they're only DOSin themselves, no?

StackOverflow and Cloudflare have both self-DoSed themselves with such flaws, causing downtime.
Post reply on HN