Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Always Review Your Dependencies, AGPL Edition

agwa.name

Post reply on HN
Print view View original

171–180 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#171

Post by vmchale »

marcus_holmes wrote: post #70
cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

similarly, I refuse to use JS libs that have ridiculous dependency trees (most annoyingly, including Webpack, which means my Vue setup is more interesting than it needs to be). I was explaining why to a friend, and it appears that no-one takes this threat seriously, not even in secure/financial apps. Like you, I wonder if I'm missing something obvious. Why does the npm dependency trust nightmare give me the screaming…

> it appears that no-one takes this threat seriously, not even in secure/financial apps.

I think that's pretty standard for our industry, even outside the often comically lazy world of JS.

Re: Always Review Your Dependencies, AGPL Edition

#172

Post by vmchale »

galangalalgol wrote: post #156
ncmncm wrote: post #78

Earlier quoted context omitted.

It's not just you. Screaming heebie-jeebies is exactly the correct response. People who don't worry about it tell themselves that nothing that matters very much is coded in javascript, obvious exceptions notwithstanding. Maybe the only practical way left to avoid it is to avoid javascript for things that matter, and to avoid products constructed with javascript for uses that matter. This might be an unpopular observa…

Indeed, rust is a likely wasm choice and it is working on an npm nightmare of its own with crates.io. A blessed crates pack is sorely needed to fill out the intentionally thin stdlib in cases you can't afford a dependency tree 20 layers deep for all the reasons mentione on this thread.

It's unfortunate that Rust is so tied to cargo, and unfortunate that cargo insists on allowing multiple versions of a dependency. If you point out that cargo is poorly designed everyone just yells and you and says you don't understand.

Re: Always Review Your Dependencies, AGPL Edition

#173

Post by vmchale »

seemslegit wrote: post #120
cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

Seems like negative comments about npm are getting shadowbanned here, so let's try again: npm-based software engineering culture is utterly irresponsible and should be viewed as a liability for both a company and its users.

The npm dependency model is a nightmare. All the more shameful given that it's backed by a for-profit entity that charges its users.

Re: Always Review Your Dependencies, AGPL Edition

#174

Post by vmchale »

baby wrote: post #151
cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

Rust is on this path as well, the small standard library pretty much forces people into using a ton of tiny dependencies. Compiling a rust project is exactly like using npm and seeing a never ending list of deps

IMO the main problem with Rust is that it's tied to cargo, which tries to link in multiple versions of the same crate.

Re: Always Review Your Dependencies, AGPL Edition

#175

Post by steveklabnik »

matheusmoreira wrote: post #169
baby wrote: post #151

Earlier quoted context omitted.

Rust is on this path as well, the small standard library pretty much forces people into using a ton of tiny dependencies. Compiling a rust project is exactly like using npm and seeing a never ending list of deps

The underlying problem is the lack of curation. Micro-dependencies that are widely used and have been reviewed for quality should be promoted to a group of standard packages. They'd still be dependencies like any other but they'd be officially maintained and installed by default. Another problem with npm: every package gets its own copy of its dependencies. Not sure if Rust does that.

Cargo de-duplicates packages as much as possible, and only includes multiple copies if there are multiple incompatible versions required.

Re: Always Review Your Dependencies, AGPL Edition

#176

Post by marcus_holmes »

ncmncm wrote: post #78
marcus_holmes wrote: post #70

Earlier quoted context omitted.

similarly, I refuse to use JS libs that have ridiculous dependency trees (most annoyingly, including Webpack, which means my Vue setup is more interesting than it needs to be). I was explaining why to a friend, and it appears that no-one takes this threat seriously, not even in secure/financial apps. Like you, I wonder if I'm missing something obvious. Why does the npm dependency trust nightmare give me the screaming…

It's not just you. Screaming heebie-jeebies is exactly the correct response. People who don't worry about it tell themselves that nothing that matters very much is coded in javascript, obvious exceptions notwithstanding. Maybe the only practical way left to avoid it is to avoid javascript for things that matter, and to avoid products constructed with javascript for uses that matter. This might be an unpopular observa…

hmm, I always assumed it's a single "heeby-jeeby" and therefore multiple "heeby-jeebies", because that's how English mostly does singular/plural.

But the repetition in "heebie-jeebies" looks more appealing. Even if grammatically unlikely.

I'm confused now.

Is "heebie-jeebies" intrinsically plural (like "sheep"), and therefore the pluralisation doesn't matter?

Is there even such a thing as a single "heeby-jeeby"?

Re: Always Review Your Dependencies, AGPL Edition

#177

Post by brlewis »

seemslegit wrote: post #120
cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

Seems like negative comments about npm are getting shadowbanned here, so let's try again: npm-based software engineering culture is utterly irresponsible and should be viewed as a liability for both a company and its users.

Please don't post vague flame bait.

Re: Always Review Your Dependencies, AGPL Edition

#178

Post by TeMPOraL »

atoav wrote: post #160
sime2009 wrote: post #140

Earlier quoted context omitted.

The risk profiles of the examples you gave are not comparable to that of most software projects. Most software projects are harmless if they crash. No one is hurt. Software projects which do risk injury and dead, for example embedded medical, get a lot more engineering and QA.

While you are certainly right that certain fields are more deadly than others, less direct things like loosing personal pictures of someone, leaking someones unencrypted medical data, getting some abstract score wrong, etc. can seriously impact your users lifes. And even the more security critical fields constantly do things wrong. When you can change the workings of an insulin pump that is in someone elses body remo…

I wouldn't bet on the industry reforming itself. If all other industries are an indication, quality and safety needs to be regulated in.

Boeing case is indeed good example. They cared about safety of their planes up until they figured out how to make more money by skillfully avoiding having to care. It looks like it blew up in their faces, but I'm not so sure of that - they're more than "too big to fail", they're a strategic company for the US, so the military won't let them fail.

> If we put in the effort to make something a little easier, safer and faster that people use every day, you impact more lifes than you might know.

My point (here and in parallel reply) is, if "being a professional" is defined as being focused on business objectives and bringing in revenue through your work, then putting in that effort, making things easier, safer and faster, are all - by that definition - unprofessional behavior. Sacrificing time and revenue for goals the market doesn't care about.

Re: Always Review Your Dependencies, AGPL Edition

#179

Post by SkyBelow »

cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

>Nobody except me seems to see a problem there, despite me being able to point out specific security incidents.

This seems to apply to security in general. Security these days is doing the minimum amount needed to check some boxes that you are now secure. I suspect a lot of this is driven by incentives. There is few negatives to an individual to use bad security over good security, and the costs of good security means less of the 'good stuff' being developed which results in worse reviews and less prestige. And if people are hacked, the blame is primarily placed on the hackers with little danger to the developers and often even less danger to the company (they might have to spend 5% of the budget they saved on PR to repair their image).

I'm not sure how to fix the issue with prioritization of security. My first guess would be by changing the incentives to companies so they bear the liability in identity theft instead of the user (the very concept of identify theft is a trick to blame the end consumer instead of either the business leaking data or the business giving away money without verifying if data is accurate).

Re: Always Review Your Dependencies, AGPL Edition

#180

Post by TAForObvReasons »

danShumway wrote: post #157
cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

I don't think the NPM ecosystem is in a great security position, but the pushback I'd make here is that you should be reviewing your Go dependencies as well. If you're looking at the NPM ecosystem and saying, "the number of dependencies is problematic because it takes a long time to review them", I agree with you. If you're looking at the Go ecosystem and saying, "there are fewer dependencies, so I don't need to revi…

"the number of dependencies is problematic because it takes a long time to review them"

The dependencies themselves are generally smaller and more self-contained. Arguably it is easier to review since the side effects and cross-module behaviors are much more pronounced (it's generally deemed a "bad thing" by the community for modules to make unnecessary global actions)

Post reply on HN