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

151–160 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#151

Post by baby »

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

Re: Always Review Your Dependencies, AGPL Edition

#152

Post by eitland »

pomhellxml wrote: post #59
eitland wrote: post #52

Earlier quoted context omitted.

There's also Java and .NET for those who want better IDE support, better dependency management (without recursively downloading hundreds of packages), and a more traditional language and more fully featured language. PS: I came to statically typed languages as an adult, I actually disliked those languages before I had the lightbulb moment, so I think I might even be more qualified than everyone who hasn't managed to…

Whilst the dependency management story on Node, Python is sub-par, it’s not all roses in Java land either with Maven and POM file XML-hell.

Actually, again as someone who has some real life experience with a number of different systems, including

- pip for Python,

- NPM,

- Nuget

- and Maven (and Ant)

Maven is by far my favorite, despite XML.

In fact, give how small pom files are and how little you have to deal with them (if you know what you are doing) I find it amazing how many comments I have had to read about "XML-hell" etc.

Re: Always Review Your Dependencies, AGPL Edition

#153

Post by gardaani »

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

It is also difficult to know which dependencies have unsafe code. There's good discussion about it on reddit: https://www.reddit.com/r/rust/comments/ekpa3i/is_anyone_conc...

Re: Always Review Your Dependencies, AGPL Edition

#154

Post by gpm »

squiggleblaz wrote: post #81
lifthrasiir wrote: post #31

Earlier quoted context omitted.

If you define the "modernization" as mindlessly switching to a trending framework or library, the cost is inevitable even without package managers.

You don't need to mindlessly switch to a trending framework or library. Try upgrading typescript to the latest version. I think that's a fair definition of "modernisation" and something which should be benign. But now all of a sudden you have to upgrade every dependency to the latest version - or write your own .d.ts files - since they're typically written to the current library version - typescript version combinati…

The rust eco system has done a pretty good job at this.

The language and standard library is always backwards compatible (minor security fixes excepted). So updating to a newer language version just works.

Major libraries at the roots of many dependency trees have upgraded in backwards incompatible ways a few times, but the community has pretty consistently come together and helped move every other library that anyone uses to the new version.

Re: Always Review Your Dependencies, AGPL Edition

#155

Post by ausjke »

jaredklewis wrote: post #95
iforgotpassword wrote: post #76

Earlier quoted context omitted.

I'm not a web dev, not a JavaScript fan, but out of pure curiosity I've been playing with the idea of doing my next side project in node, just to get an idea of what modern Js feels like. But the whole dependency hell, left-pad and the likes are a real turnoff. So what I'd probably end up with is coding in pure Js without a package manager or "build system". Basically like you did PHP in the 90s. The question is whet…

It’s slowly expanding, but JS has an anemic standard library. The node platform adds a little, but yo’re still miles away from a typical standard library like Java or python. If you want to have 0 dependencies, you will have to write a lot of code to do things that would just be a line or two in most other languages.

I have long hoped Nodejs has a "standard library" of its own

Re: Always Review Your Dependencies, AGPL Edition

#156

Post by galangalalgol »

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…

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.

Re: Always Review Your Dependencies, AGPL Edition

#157

Post by danShumway »

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 review them", then that's a security antipattern.

The better way to phrase this to your team is that you need to review dependencies, period. The NPM ecosystem isn't problematic because it introduces a new requirement to review dependencies, it's problematic because reviewing dependencies is harder. You can use NPM all you want for security-sensitive code. You just have to spend the extra time to review dependencies, which means bringing in new dependencies will be much slower than in a shallower ecosystem like Go's.

That's the point of OP's article. You can't skip reviewing dependencies in any ecosystem, in part because all of our ecosystems across the board have crap sandboxing and permissions, but also because of license issues and quality issues like the author found. There is no shortcut for that, whether you're using Ruby, Go, Python, whatever. You have to review your dependencies.

Re: Always Review Your Dependencies, AGPL Edition

#158

Post by [deleted] »

oblio wrote: post #46
randomsearch wrote: post #26

Earlier quoted context omitted.

Nearly spat out my cereal, thanks. Funny because accurate. As a relatively new node dev, this is what keeps me awake at night.

And his comment is copy-paste from Reddit: https://old.reddit.com/r/programming/comments/ekjacu/this_is... Slightly ridiculous that we're getting to this point :-)

[deleted]

Re: Always Review Your Dependencies, AGPL Edition

#159

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…

Yeah, my back-end is in Go, so being able to write the front end in Go as a simple cross-compile is great, if it was that simple.

We're a long way from it being that simple. There are "hello world" examples, but nothing close to a working GUI in Go-WASM yet.

I'd love a clone of Vue in Go-WASM. Just saying, if anyone out there wants to give it a try ;)

Re: Always Review Your Dependencies, AGPL Edition

#160

Post by atoav »

sime2009 wrote: post #140
atoav wrote: post #42

Earlier quoted context omitted.

> I'd think the comparison goes the other way around :) Only in the Software industry. This is however not normal: * Mechanical Engineering: Hobbyist bridge vs. professional Bridge – which one should you be able to trust more to carry you? * Electrical Engineering: Hobbyist wall wart vs. professional wall wart – which one should you be able to trust more not to burn your house down? * Medical Treatment: Hobbyist vs.…

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 remotely and it turns out neither the programmer nor the regulators thought authentification might be a good idea, you know something is very wrong with a whole profession.

The latest Boeeing example is more of a regulatory failure, but somwhere someone sat and coded the behaviour that killed multiple hundreds of people.

We as programmers are just as responsible for what our stuff is doing as anybody else. Maybe even more so, because the work of our hands multiplies. 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. And the same is true for the other direction.

Why is it, that software glitches are always seen as a god given higher force, that nobody could have prevented? I know managing complexity is hard, but there is proof out there that it can be done if wanted. We could wait till we are forced to do this by law, or (preferebly) develope at least a pinch of ethos for our own work.

Post reply on HN