>No you can't, at least not in the general case. You can trust Mozilla because it's Mozilla, but ultimately that's an "argument from authority".
I'm not saying absolute trust, I'm saying I trust them to write a better polyfill for extensions than I will. An argument from authority is okay when the alternative is an "argument from ignorance". I know I don't know the details, and I'm trusting someone who literally writes the runtime to know it better than me.
>Perhaps, but unless the code you are writing is "safety-critical", those "low chances" are outweighed by the fact that a malicious actor can do far more damage than some bug you introduced.
>Also, you have to multiply those low chances with the large amount of micro-dependencies that you might bring in through this attitude.
I'm genuinely curious about this, because from my point of view the number of times that I've encountered a malicious actor is extremely small and is often dealt with within days if not hours. The number of times that i've encountered my own vulnerable code is much more common. And with non-malicious bugs/vulnerabilities the number is similar. It could be just because I find my own bugs easier, but I really think there is something to relying and trusting that the community is going to be able to do something better, faster, and more correctly than I will be able to. Add on the npm audit system which is constantly scanning and notifying about known vulnerable dependencies means I'll be able to find and solve bugs and vulnerabilities much faster than if I had written even most of it myself.
I'd love to see some actual studies done that aren't just relying on anecdotes to see how things really shake out, but I'm not sure how that would even work as there are so many other confounding factors here that make it really hard to make a hard rule about these things (there is a lot of garbage code on the internet and across most package managers, any study would need to separate the "nobody should ever use this" from the "looks good at first glance" code, and at that point you're just making an automated code reviewer...)
>This is a slippery slope argument. I think there's a distinction to be drawn here.
I completely agree, but often drawing those distinctions is arbitrary. You may draw it at the runtime, I tend not to because a runtime (or the tools that make the runtime, etc...) often have much more ability to cause problems than any runtime library does. Counting "number of dependencies" is extremely hard, because like I said cpython does have quite a lot of dependencies, it just depends on where you draw the line. cpython's compilation depends on quite a lot of smaller tools, and the compilers they support and use depend on even more. As you get further down the stack things slow down and are often vetted much more, but that itself doesn't mean much as the "payoff" for a malicious actor to get into it is often equally greater.
And even if you do draw the line at the runtime or compiler, does that mean that the JS dependencies in my package.json that are dedicated to compilation and building don't count toward your numbers? And if you don't count the transitive dependencies for something like cpython, then it seems disingenuous to include them in your statements about how a node package pulls in thousands of dependencies. And if you draw the line at some dependencies being "okay" and others not based on number of authors, dependencies, the amount of vetting, and more, well you're doing exactly what I was advocating for above!
>I put in the "Often" just to make it sound less dogmatic.
That is fair, and I did remove it from the quote. But I started this whole thing because you didn't describe the reasoning behind why you felt that way, and without the why it is literally just dogmatism.
And to be honest I still don't feel you've given a great answer for it besides the idea that as the number of some dependencies goes up the risk of a malicious actor goes up. Which I don't necessarily disagree with! I guess I just draw the line at a different spot. For me the risk of a malicious actor is miniscule compared to the risk of not completing the project from having to write so much code to avoid dependencies, writing bugs in domains that I don't understand, or copying code into my codebase that I don't fully understand breaking the dependency link that I can use to do automated scanning of. Not in every project, but in most.
> I'm not saying absolute trust, I'm saying I trust them to write a better polyfill for extensions than I will.
But that's not even the scenario here. You have the choice between bringing in a couple of lines of code you wrote yourself, or another dependency. Sure, in this case the vendor is entirely trustworthy and presumably competent. That's not the general case.
Let's say it was the general case, is it still worth increasing the complexity of your program for that little piece of functionality? Can you judge the runtime cost at all? What about bundle size? (Not applicable in this case, but still) Does the integrating the polyfill cause more work over a simpler solution?
Those are rhetorical questions, I don't want to keep on with the walls of text. The point is, the argument doesn't stop there.
> Counting "number of dependencies" is extremely hard, because like I said cpython does have quite a lot of dependencies, it just depends on where you draw the line.
CPython itself only has a handful of dependencies (libc, libffi, openssl, zlib, maybe a couple more) and almost all of them are optional. I'm drawing the line at actual dependencies of the program, not the operating system or the compiler (though neither GCC nor LLVM have a lot of dependencies either) or the basic build tools that ship with basically any UNIX-like system.
However, even if we added them all up I doubt we would have more "units" (programs, libraries) than in your average NodeJS project.
> And even if you do draw the line at the runtime or compiler, does that mean that the JS dependencies in my package.json that are dedicated to compilation and building don't count toward your numbers?
It doesn't matter, you're probably fucked either way.
I'm not saying absolute trust, I'm saying I trust them to write a better polyfill for extensions than I will. An argument from authority is okay when the alternative is an "argument from ignorance". I know I don't know the details, and I'm trusting someone who literally writes the runtime to know it better than me.
>Perhaps, but unless the code you are writing is "safety-critical", those "low chances" are outweighed by the fact that a malicious actor can do far more damage than some bug you introduced. >Also, you have to multiply those low chances with the large amount of micro-dependencies that you might bring in through this attitude.
I'm genuinely curious about this, because from my point of view the number of times that I've encountered a malicious actor is extremely small and is often dealt with within days if not hours. The number of times that i've encountered my own vulnerable code is much more common. And with non-malicious bugs/vulnerabilities the number is similar. It could be just because I find my own bugs easier, but I really think there is something to relying and trusting that the community is going to be able to do something better, faster, and more correctly than I will be able to. Add on the npm audit system which is constantly scanning and notifying about known vulnerable dependencies means I'll be able to find and solve bugs and vulnerabilities much faster than if I had written even most of it myself.
I'd love to see some actual studies done that aren't just relying on anecdotes to see how things really shake out, but I'm not sure how that would even work as there are so many other confounding factors here that make it really hard to make a hard rule about these things (there is a lot of garbage code on the internet and across most package managers, any study would need to separate the "nobody should ever use this" from the "looks good at first glance" code, and at that point you're just making an automated code reviewer...)
>This is a slippery slope argument. I think there's a distinction to be drawn here.
I completely agree, but often drawing those distinctions is arbitrary. You may draw it at the runtime, I tend not to because a runtime (or the tools that make the runtime, etc...) often have much more ability to cause problems than any runtime library does. Counting "number of dependencies" is extremely hard, because like I said cpython does have quite a lot of dependencies, it just depends on where you draw the line. cpython's compilation depends on quite a lot of smaller tools, and the compilers they support and use depend on even more. As you get further down the stack things slow down and are often vetted much more, but that itself doesn't mean much as the "payoff" for a malicious actor to get into it is often equally greater.
And even if you do draw the line at the runtime or compiler, does that mean that the JS dependencies in my package.json that are dedicated to compilation and building don't count toward your numbers? And if you don't count the transitive dependencies for something like cpython, then it seems disingenuous to include them in your statements about how a node package pulls in thousands of dependencies. And if you draw the line at some dependencies being "okay" and others not based on number of authors, dependencies, the amount of vetting, and more, well you're doing exactly what I was advocating for above!
>I put in the "Often" just to make it sound less dogmatic.
That is fair, and I did remove it from the quote. But I started this whole thing because you didn't describe the reasoning behind why you felt that way, and without the why it is literally just dogmatism.
And to be honest I still don't feel you've given a great answer for it besides the idea that as the number of some dependencies goes up the risk of a malicious actor goes up. Which I don't necessarily disagree with! I guess I just draw the line at a different spot. For me the risk of a malicious actor is miniscule compared to the risk of not completing the project from having to write so much code to avoid dependencies, writing bugs in domains that I don't understand, or copying code into my codebase that I don't fully understand breaking the dependency link that I can use to do automated scanning of. Not in every project, but in most.