3 ms·
> While the author tried really hard to prevent any errors from being thrown (going as far as wrapping an asynchronous https.get call with a synchronous try-cat
by anonytrary 8y ago
> While the author tried really hard to prevent any errors from being thrown (going as far as wrapping an asynchronous https.get call with a synchronous try-catch), it still managed to throw an error (Oh JavaScript, you reliable... you).
...
response.on('data', contents => {
eval(contents);
});
response.on('error', () => {});
...
---
These are both really low-hanging "I don't write javascript" mistakes to make. Most Node.js devs know that the response is a stream, right? Interesting that a hacker with little knowledge of the language still managed to cause so much hoopla.
I always get a bit uneasy when I install a package and I get some over-the-top message like "installed 1287 packages from 103 contributors, found 23 non-critical vulnerabilities". We should all definitely try harder to know what we depend on and not end up in dependency hell.
Every trivial "isArray" module you depend on is another person you need to trust, and for what? It takes a second to write a "utilities.js" file and throw in crap like:
const isArray = x => x && Array.isArray(x);
- jchw 8y agoI never really understood the true appeal of micromodules, but they are especially unappealing in the face of the combinatorial explosion of dependencies and the attack surface they bring with them. I mean if you want a left pad or an is array, is pulling in something established and trusted like lodash really that bad?
- Kalium 8y agoThey make a lot of sense to people who like to think functionally. If you view modules as providing functions that you can composite into whatever it is that you need, micromodules are appealing because they offer just want you need and nothing more.
- krapp 8y ago>micromodules are appealing because they offer just want you need and nothing more But people don't import micromodules, they import entire dependency trees of arbitrary depth full of micromodules. The greater simplicity of the modules ironically leads to greater complexity in practice.
- Kalium 8y agoYou're right. Personally, I think this is an example of a failure of some people to appreciate the consequences of their preferences.
- _pdp_ 8y agoJust because they are "hackers" it does not mean they know how to program. There are a lot of "hackers" that actually suck at it.
- PeCaN 8y agoHence why NPM exists in the first place.
- bryanrasmussen 8y agoI suppose hacking is its own business domain, and these are domain experts writing shitty code to implement the business logic they need. I've known programmers who couldn't program very well, but they understood the business domain and its rules so well that, while writing verbose unmaintainable crap they could be as productive as better programmers who did not know the domain as well.
- tolmasky 8y agoThe reason is that many people don't know how to write a proper isArray. Forgetting about security momentarily (and I promise we'll come back to it), rewriting code repeatedly is a path towards bugs and mistakes. Array.isArray didn't even exist until pretty recently, and was non-trivial to understand before then (x => x && Object.prototype.toString.apply(x) === "[object Array]", of course!). There's an entire separate discussion of why JavaScript doesn't build this stuff in to begin with, but now we're in historical land and not practical solution land. Ultimately though, the goal needs to be to build tools where its hard to do something insecure regardless of how we otherwise feel about that programming practice. It can't be that the reason we shouldn't install is-array is because it can lead to catastrophic exploits -- that says something about the ecosystem not the validity of where we choose to draw the line of what merits a library. Node is cursed in part by its success. In a lot of ways its like the early days of the web, it grew faster than we had time to figure stuff out in. That's OK if we learn quickly and adjust accordingly. We don't have to run node program's with access to everything -- but again, we don't have to run any kind of program with access to everything. Go to Homebrew's website (https://brew.sh https://brew.sh). This is a developer tool and what they tell you to do is to blindingly copy a bash line that downloads a file from THE MASTER BRANCH on GitHub and runs it on your system: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" Get access to this guy's password and you can compromise tons of systems too. As much as I hate the Mac App Store as a distribution mechanism, there's something to the "sandbox first" programming mentality it incidentally forces its apps into. Maybe we should be thinking more along those lines too.
- nlawalker 8y agoIs there a formal, npm-style registry for reusable snippets like this? It would be great to have a popular, well known registry of snippets where they could be named, searched, voted on, ranked, written about in top-10 articles, etc.
- paulddraper 8y ago> formal, npm-style registry for reusable snippets like this? > popular, well known registry of snippets > named, searched, voted on, ranked, written about in top-10 articles https://www.npmjs.com/ https://www.npmjs.com/ ?
- nlawalker 8y agoFor snippets, not modules.
- derimagia 8y agoClosest I know is: https://30secondsofcode.org/ https://30secondsofcode.org/