Npm Audit: broken by design? • Hacker News Board

Re: Npm Audit: broken by design?

#251

Post by junon » Thu, Jul 08, 2021, 2:26 PM UTC

tekknik wrote: post #249

junon wrote: post #243

Earlier quoted context omitted.

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.

Building the same project even without re-installing node modules has absolutely no guarantee of reproducibility.

Re: Npm Audit: broken by design?

#252

Post by cphoover » Thu, Jul 08, 2021, 2:50 PM UTC

argomo wrote: post #189

cphoover wrote: post #41

Earlier quoted context omitted.

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…

Perhaps the problem is that user's are entirely too entrenched with using blackbox frameworks they don't fully understand like create-react-app, and not that we have a tool that discloses when these frameworks contain vulnerable dependencies.

If we are in a situation where swapping out dependencies becomes so difficult that we just throw our hands up, is that really an issue with tooling?

EDIT:

BTW I'm not opposed to a PR that would allow for a .gitignore style list to ignore warning on specified deps. That could be useful. The issue I have would be respecting other peoples "auditignore" list or whatever... Because just because someone like @danabramov thinks including some package is not a threat, I may or may not agree with him.

Re: Npm Audit: broken by design?

#253

Post by eropple » Thu, Jul 08, 2021, 2:57 PM UTC

schneidmaster wrote: post #196

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…

> This attitude makes me kind of uncomfortable. I think the point though is that security warnings need to be actionable and high-signal. Experienced folks are absolutely tuning out the security warnings on npm install, because 95% of the warnings are like the examples in the post -- I know they don't affect me/my use case and there's nothing I can do about them anyway. The effect is only compounded for novices who r…

Yeah, this I totally agree with. Actionable alerts are important. The idea that novices should be opted out of ecosystem security concerns generally, less so (not least because they'll create their own security problems in the process).

Re: Npm Audit: broken by design?

#254

Post by lioeters » Thu, Jul 08, 2021, 3:48 PM UTC

j1elo wrote: post #121

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

It reminds me, that exact issue is why I switched from `npm` to `yarn` a few years ago. Sad to see that it has not been solved after all this time..

Re: Npm Audit: broken by design?

#255

Post by cphoover » Thu, Jul 08, 2021, 6:22 PM UTC

danabramov wrote: post #21

raziel2p wrote: post #16

Earlier quoted context omitted.

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.

>Just upgrade it to be on the safe side. A big part of the problem is there is no reliably way to "just upgrade it" today in npm: - `npm audit fix --force`, which is supposed to do that, is buggy and doesn't work - There is no way to override a transitive dependency with npm (there is with Yarn though, so hopefully this feature will come to npm soon) - Sometimes the fix in transitive dependency _also_ includes breaki…

> * - There is no way to override a transitive dependency with npm (there is with Yarn though, so hopefully this feature will come to npm soon)*

I do not think this is a good idea as it allows consumer's of a library to utilize that dependency with untested, and unspecified transitive decencies What happens when a transitive dependency breaks the 1st level dependency? What a PITA that would be to try and fix.

Re: Npm Audit: broken by design?

#256

Post by smsm42 » Thu, Jul 08, 2021, 7:02 PM UTC

trunnell wrote: post #109

smsm42 wrote: post #101

Earlier quoted context omitted.

I think if the attacker got as far as deploy their code in your CI/CD pipeline and prod system, there's no "quickly" fixing it. There's a full shut down, restoring from trusted backup, full data and code audit and a lot of pain in the future validating and restoring the code and the data. Quick rebuild is not something that would be your priority there - how do you know this quick build won't be compromised anyway? I…

I think the typical scenario is that you understand how big of problem it is only in retrospect. In the moment, your first thought is that there is some type of quick fix that will restore functionality (if your site is down) or evict the intruder if something funny is detected. As a sibling commenter said, most teams would try to deploy a previous known-good build asset. But I stand by my point that a DoS of a devel…

I think you're confusing scenarios here. If you have known-good build, then there's no way it is compromised by regexp DOS attack - because that's the build that happened before the attack. So if you build that - setting aside the wisdom on doing that on a compromised system - the regexp DoS is not relevant. If you are building the modified code then one should definitely question why would you want to do something like that - build and deploy known compromised code.

That seems to be the root of your confusion - it's not that development system DoS is not bad, it's that if you are at the point it's possible your security is already broken in much bigger way. It's like complaining that running "rm -rf /" under root would wipe all your files and that's a DoS - without taking into account that if somebody could run commands under root on your system it's not your system anymore. It's not that wiping all the files isn't bad - it's that the reason for why the situation is bad is much earlier that that.

Re: Npm Audit: broken by design?

#257

Post by stjohnswarts » Fri, Jul 09, 2021, 5:41 AM UTC

IggleSniggle wrote: post #191

alerighi wrote: post #153

Earlier quoted context omitted.

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.

As a beginner _just to npm_ I can imagine getting totally freaked out and worried that my whole system was _potentially_ compromised after seeing a “Critical” vulnerability reported as installed on my system. After all, npm can execute any script with the users permissions on install…except often (compared to bash) it’s less easily inspected due to the common use of nested dependencies! I, too, would delete my node_m…

Who doesn't run an npm based app in a jail/vm/etc and as a regular user with any more than the bare minimum access needed to get it's job done?

Re: Npm Audit: broken by design?

#258

Post by krageon » Fri, Jul 09, 2021, 11:43 AM UTC

raxxorrax wrote: post #242

krainboltgreene wrote: post #209

Earlier quoted context omitted.

> 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. P…

If it's too hard for you to develop a library hardened against DoS attacks which are pretty trivial to perform perhaps it's a good thing that npm audit flags your library as containing bugs.

Re: Npm Audit: broken by design?

#259

Post by tekknik » Fri, Jul 09, 2021, 1:06 PM UTC

junon wrote: post #251

tekknik wrote: post #249

Earlier quoted context omitted.

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.

Building the same project even without re-installing node modules has absolutely no guarantee of reproducibility.

Oh please explain what’s different. The entire code chunk is the same. How is that not reproducible?

Re: Npm Audit: broken by design?

#260

Post by junon » Fri, Jul 09, 2021, 1:17 PM UTC

krageon wrote: post #258

raxxorrax wrote: post #242

Earlier quoted context omitted.

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. P…

If it's too hard for you to develop a library hardened against DoS attacks which are pretty trivial to perform perhaps it's a good thing that npm audit flags your library as containing bugs.

A bit pretentious to imply you're better than everyone else at writing regular expressions, so much so that you'd never write one that had exponential time/space complexity on large inputs.

Or do you just not understand what regex DoS vulnerabilities are?

Either way, you come across very foul and condescending in this comment.