161–170 of 237 posts
This is important. It looks like the organization is submerging; they've deleted their NPM account and the package and emptied their GitHub repo. This should be signal boosted as hard as it can be managed, because this is rough stuff.
Earlier quoted context omitted.
And nobody but the most tinfoily of us is going to do that. So short of a web of trust or delegation, you get nothing more than a checksum.
>nobody but the most tinfoily of us is going to do that Are you characterizing people who verify keys as crazy? It's not like you can't just reach out to @kentcdodds and get an answer in under 5 hours as Oscar Blomsten just did in the OP.
Earlier quoted context omitted.
I can't reply directly, but in another subtree you asked: > Which part of the statement implied "vilgilate justice." To put my own 2 cents in: Doxxing someone is generally considered an attack, at least in some internet circles. It's pretty vigilante if you ask me, especially when we've seen some pretty striking examples of doxxing gone wrong in the past.
If you connect to my resources and use my systems to hurt other people, you don't really have an ethical leg to stand on if I share what details about you I have with law enforcement and other service providers. It's absolutely an attack, but it's an "attack" of a kind that is acting to end misuse and widespread tampering. It's difficult to imagine a coherent ethical system that gives the author of malicious software…
The problem does not lie in attacking bad people, the problem is that there is a high risk that you THINK you've identified who the bad actor is but actually the person you decide to "retaliate" against had nothing to do with what was done to you. That's why we leave law enforcement to the law enforcement officials and justice to the justice system. Even they make a lot of mistakes but at least there is a process that gives a chance for the truth to be found.
But sharing info about a suspect with law enforcement is what you should do yes.
This is issue is not so hard to deal with. 1. For every big, important package, you can probably count on number of downloads/stars a library has to attest its trustworthiness. 2. For small packages, you should always look at the code directly. Search npm, see the GitHub repository link, click, read the source to see if it more-or-less does what you want. I think a lot of people do this already. 3. Typosquatting is s…
Or package authors should start using scoped packages. Instead of publishing as cross-env you publish as @guy/cross-env That makes typosquatting harder, and can help give users some ideas of packages which are by the same authors. NPM could help by allowing packages to be published both to the "global namespace" AND as a scoped package automatically. (In other words, always allow accessing any global package by it's…
Is there an api to query recent NPM packages, as well as get a full list of packages? It'd be interesting to write a tool that monitors as packages are added to npm, compare them against the existing list, and check for potential typo-squatting. Like, remove dashes, check Levenshtein distance, etc. I mean, NPM themselves should be doing that but ... since they aren't, might as well do it for them, ya?
Earlier quoted context omitted.
Hashes already exist. The problem is not a lack of integrity verification. We have that. The problem is not a lack of identity verification, we haven't really shown that NPM is lacking for that. The problem is one of addressing. People want to get packages by a utf8 and natural language string, followed by a version boundary check. If people referred to packages by their proper hash (as one does when referencing valu…
Yeah I'm not really following how users desiring a natural-language tuple-looking thing prevents proper identity verification. Even without namespacing strong identity controls (signature verification and preventing unauthorized accounts from posting under a taken name, for example) can prevent most attacks short of typosquatting.
Earlier quoted context omitted.
I can explain how it can be done. Let's say you need a new dependency. You can't just add it to the project. Management would kill you. There's a lot of checks you have to make. Like licenses and signatures. In this case, you're concerned about signatures. I'll stick to that. If I believe I need crossenv, I see it advertises kent@doddsfamily.com as the author. I look up Kent Dodds. I find various bits of information…
Why would the malicious user advertise the email associated with crossenv as kent@doddsfamily.com and not kent@dodds.family? Attacker could control the latter and hand you an evil cert?
It's the same way you gain trust in something in real life, by watching actual behavior of someone over time. It is just assisted by technology.
Then you can ignore the issue of email completely, because you're not basing your trust on authority of the author, but on his track record as determined by you.
I bet you'll not find many attackers who would maintain some hijacked package for a few months, before launching their attack. Original author would probably notice something fishy too, given enough time.
Earlier quoted context omitted.
There's a minor regex error in the one-liner: not escaping the dot, which matches any character. Fortunately that won't cause any false negatives, and will only incorrectly match weird things like fabric9js Fixed: npm ls | grep -E "babelcli|crossenv|cross-env\.js|d3\.js|fabric-js|ffmepg|gruntcli|http-proxy\.js|jquery.js|mariadb|mongose|mssql\.js|mssql-node|mysqljs|nodecaffe|nodefabric|node-fabric|nodeffmpeg|nodemaile…
I would add a "@" npm ls | grep -E '(babelcli|crossenv|cross-env\.js|d3\.js|fabric-js|ffmepg|gruntcli|http-proxy\.js|jquery\.js|mariadb|mongose|mssql\.js|nodecaffe|nodefabric|node-fabric|nodeffmpeg|nodemailer-js|nodemailer\.js|nodemssql|node-opencv|node-opensl|node-openssl|noderequest|nodesass|nodesqlite|node-sqlite|node-tkinter|opencv\.js|openssl\.js|proxy\.js|shadowsock|smb|sqlite\.js|sqliter|sqlserver|tkinter)@'
grep -r -i --include package.json -E '(babelcli|crossenv|cross-env\.js|d3\.js|fabric-js|ffmepg|gruntcli|http-proxy\.js|jquery\.js|mariadb|mongose|mssql\.js|nodecaffe|nodefabric|node-fabric|nodeffmpeg|nodemailer-js|nodemailer\.js|nodemssql|node-opencv|node-opensl|node-openssl|noderequest|nodesass|nodesqlite|node-sqlite|node-tkinter|opencv\.js|openssl\.js|proxy\.js|shadowsock|smb|sqlite\.js|sqliter|sqlserver|tkinter)@'