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

241–250 of 268 posts

Re: Npm Audit: broken by design?

#241

Post by wickedsickeune »

junon wrote: post #232
esprehn wrote: post #226

Earlier quoted context omitted.

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.

There is a way, but it's troublesome. Create a docker image with installed node modules. Save it, and from then onwards you have frozen node modules. If you need a new dependency/updated version you need to create a new image and npm i.

Re: Npm Audit: broken by design?

#242

Post by raxxorrax »

krainboltgreene wrote: post #209
junon wrote: post #137

Earlier quoted context omitted.

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…

> 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. Because this isn't true. Just because you're experience this effect (which blows), doesn't mean the tool and related tooling are somehow broken. These Regex issues should be fixed, libraries should update to safe versions, thin…

I think it helps to inform the developer about possible issues, but I think in most cases depending on the software this is plainly not relevant and can be ignored. I wouldn't classify it has high severity. Also, It might just not be trivial to develop a regex library that cannot be DDOSed or the mechanism that was declared a vulnerability.

Might be nice to be able to tag libraries that should be ignored in audits. Perhaps there is such a function, not really a NPM expert. But if your projects has too many of these "high severity" problems, you probably stop doing them.

Still, I think the availability of such audits from the package manager is quite neat. As an embedded dev I think these are certainly luxury problems.

Re: Npm Audit: broken by design?

#243

Post by junon »

wickedsickeune wrote: post #241
junon wrote: post #232

Earlier quoted context omitted.

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.

There is a way, but it's troublesome. Create a docker image with installed node modules. Save it, and from then onwards you have frozen node modules. If you need a new dependency/updated version you need to create a new image and npm i.

That's absolutely no different than just installing and not re-installing. Docker adds nothing in this case.

Not re-building doesn't make your build reproducible. It just means that you're... not building. If I save the result of a single iteration of an RNG, I can't claim that the RNG always produces the same result because I saved the result somewhere...

Re: Npm Audit: broken by design?

#244

Post by Vinnl »

remram wrote: post #169
Vinnl wrote: post #116

Earlier quoted context omitted.

If there's a vulnerability in Webpack (a devDependency) that injects malicious code into your bundle, `npm prune --production` won't save you.

This is not a vulnerability (ie. security bug) it's an attack (ie. malicious).

It doesn't really matter how you call it; the problem is that there could be CVE's in your devDependencies that affect your production build, and pruning those dependencies after using them to create that build doesn't remove the risk.

Re: Npm Audit: broken by design?

#245

Post by bjornstar »

BHSPitMonkey wrote: post #240
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?

It's like claiming that the weeds are not dangerous in your garden not that the guidebook got them wrong.

Re: Npm Audit: broken by design?

#246

Post by Macha »

charcircuit wrote: post #225
woutr_be wrote: post #222

Earlier quoted context omitted.

This is actively going on where I work. Granted, it’s a financial company, so they take security pretty serious. During our last release, we had to go through 3 different teams, all doing different security scans. One if them is scanning all your dependencies, and its so frustrating. Because that team obviously has no idea what any of the dependencies do or how they’re being used. All they see is a red flag, and tell…

>Obviously we can’t go around updating open source code, just because the security team in our company told us. This isn't obvious to me. Most open source projects accept contribution from others.

Who says it's important to that maintainer that their project used as a build time dependency has a vulnerability if provided untrusted user input?

What if it requires major upgrades of their framework or toolchain they don't want someone doing drive by?

What if they require a CLA that your legal team won't let you sign?

Re: Npm Audit: broken by design?

#247

Post by phkahler »

TechBro8615 wrote: post #124
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 ou…

>> The answer here is probably some kind of static analysis...

So even more tools?

Re: Npm Audit: broken by design?

#248

Post by naugtur »

AaronFriel wrote: post #104

For those hoping to run npm audit in your CI/CD pipeline, I recommend this tool from IBM: https://github.com/IBM/audit-ci In highly regulated industries, shipping code flagged as having a vuln without a manual approval could be a liability. This wrapper around npm takes an allowlist argument, and our procedure is for an engineer to review the failing build, determine if the vulnerability (ugh, usually regex ddos or p…

Compare with npm-audit-resolver in terms of how the ignores are defined. It's important to not be too vague when ignoring things.

Let me plug this as it contains a lot of references https://dev.to/naugtur/do-you-need-help-with-your-npm-audit-...

Meanwhile I'll try to get someone from IBM involved in the OpenJSF collab space

Re: Npm Audit: broken by design?

#249

Post by tekknik »

junon wrote: post #243
wickedsickeune wrote: post #241

Earlier quoted context omitted.

There is a way, but it's troublesome. Create a docker image with installed node modules. Save it, and from then onwards you have frozen node modules. If you need a new dependency/updated version you need to create a new image and npm i.

That's absolutely no different than just installing and not re-installing. Docker adds nothing in this case. Not re-building doesn't make your build reproducible. It just means that you're... not building. If I save the result of a single iteration of an RNG, I can't claim that the RNG always produces the same result because I saved the result somewhere...

Where did they say they’re not building? Building your app does not mean you install the modules every time. Some apps are so large they have to be split into chunks / layers anyway. In golang this used to be the way you’d add deps, check the entire source into your version control.

Re: Npm Audit: broken by design?

#250

Post by tekknik »

jahewson wrote: post #230
esprehn wrote: post #226

Earlier quoted context omitted.

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

Ha ha, our builds are not “hermetic and reproducible” with package locks. Why? Caching.

How does caching effect this? are you’re devs / build processes not doing clean installs?
Post reply on HN