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

231–240 of 268 posts

Re: Npm Audit: broken by design?

#231

Post by hinkley »

enneff wrote: post #211
hinkley wrote: post #208

Earlier quoted context omitted.

The feature I missed about Subversion was, if you could figure out how to treat your code like a proper tree, individual teams would check out one, maybe two directories, and only the leads and operational people ever had the whole thing. I never entirely understood what it was in subversion's internals that prevented it from being used as a DCVS. We could figure out version numbers with branches and multiple repos.…

Revisions in Subversion are identified by a monotonically increasing number. How can you distribute that?

Versions are a tree structure. The implementation may have required the next revision number to be n + 1, but the data structure does not necessarily have to do that. If myself and someone else push commits, they have to be rebased and renumbered anyway, right?

Re: Npm Audit: broken by design?

#232

Post by junon »

esprehn wrote: post #226
junon wrote: post #219

Earlier quoted context omitted.

> Just because you're experience this effect (which blows), doesn't mean the tool and related tooling are somehow broken. I've been in the node scene since 0.10. That's around 10 years. My packages have billions of downloads annually. My viewpoint here carries the weight of hours of debug time and frustration and confused users of my code, as well as meeting and knowing the npm staff at the time quite personally, and…

Hope do you make your builds hermetic and reproducible without package locks?

Your builds are not reproducible with anything related to npm. Neither npm nor any bundler that I'm aware of guarantees that.

Unless we're not talking about the same reproducibility property. Also I don't know what "hermetic" means in this context but I doubt it's anything that npm solves correctly.

Re: Npm Audit: broken by design?

#233

Post by naugtur »

Let's talk about solutions. I'm late to the conversation here, responded on Twitter and went to sleep.

There's a push to address the npm audit situation. It's an initiative under the OpenJS Foundation. I kinda started the whole conversation by implementing a tool that makes it acceptable instead of ditching npm audit.

It's called npm-audit-resolver and I've written about it here https://dev.to/naugtur/do-you-need-help-with-your-npm-audit-...

Also check out the collab space and the tool itself https://github.com/openjs-foundation/pkg-vuln-collab-space https://www.npmjs.com/package/npm-audit-resolver

Re: Npm Audit: broken by design?

#234

Post by toomanybeersies »

zerkten wrote: post #142
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 the…

I'm more inclined to think the better solution would be to stop issuing CVEs for trivial "exploits" like Regex DOS, unless there's actual demonstrated uses of the exploit.

Re: Npm Audit: broken by design?

#235

Post by gforge »

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.

The package.json should be able to actively ignore vulnerability id's. As id's disappear with audits the npm audit could just remove those, eg a "prune"

Re: Npm Audit: broken by design?

#236

Post by Tomte »

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/

CVEs can be used to try and extort OSS maintainers into expensive consulting gigs: https://www.patreon.com/posts/unfixed-security-21250652

Re: Npm Audit: broken by design?

#237

Post by randomswede »

BeFlatXIII wrote: post #138
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.

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)

That sounds better than a PI that gets their jollies by shoving nitro groups into unsuspecting organic molecules.

Although I still have a deep admiration for the Klapötke "Energetic Materials" group at Munich Uni.

Re: Npm Audit: broken by design?

#238

Post by randomswede »

mulcahey wrote: post #125
prionassembly wrote: post #83

Earlier quoted context omitted.

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.

> Google built their VCS from scratch in house for scale

It's more complicated than that. Initially, there was Perforce. Then, Google grew client-side tooling on top of that ("g4", rather than "p4"). Then, someone grew client-side Git on top of that (for reasons, good or bad). And at some point, the Perforce backend simply stopped scaling, and a new backend was written (named "piper", but not the "piper" most non-Googlers think of). And once that was in place, assorted more "make it scale" tooling could be built on top of that (and, at that point, I stopped using the client-side Git, because CitC was simply That Good).

So, "from scratch" is a bit of a stretch.

Re: Npm Audit: broken by design?

#240

Post by BHSPitMonkey »

bjornstar wrote: post #228

It's really disappointing to hear an important member of the javascript community not maintaining their library and then blaming npm when people rightfully complain about it. This is like getting mad at the guidebook for showing which plants are weeds when your neighbors complain that your unmaintained garden is full of weeds. If Dan says "npm audit is a stain on the entire npm ecosystem", maybe it's safe to say that…

> This is like getting mad at the guidebook for showing which plants are weeds when your neighbors complain that your unmaintained garden is full of weeds.

Wouldn't it be more like getting mad at a guidebook which falsely claims that every plant in your garden is a weed, forcing you to second-guess all of its assertions and therefore wasting a lot of your time?

Post reply on HN