Hi eridius, thank you for your awesome comment, I really appreciate it! > But for example if your service needs to be able to make outgoing network requests to

Hi eridius, thank you for your awesome comment, I really appreciate it! > But for example if your service needs to be able to make outgoing network requests to arbitrary hosts then you can't prevent a malicious dependency from sending your private data to its own server. Ideally you would know exactly which hosts you would want to talk to, but I know and understand that is a huge amount of work, but I know companies that are by default locking down everything and only opening up for things that are asked for by the app. > If everyone followed this advice, then the advice won't change anything. This advice only helps you if other people ignore it, at which it's just "let the suckers try the new versions first". And even then it won't solve the referenced social engineering attack, because that attack was targeting one specific user, and it doesn't matter how many other users test the dependency. That you can install something that is only 1 hour old without explicitly saying yes to that, exposes you to something where even outsiders wouldn't have time to even contact npmjs.com to take down the package. And alpha and beta software is quite common, it is just now common in the node.js/npm sphere. > This doesn't help either. The malicious package was published by an authorized maintainer of the project. Presumably if the package was signed with a private key, that private key would have been given to the maintainer to use in deploying (or alternatively the maintainer would have simply asked the original author to deploy the new version). I trust Dominictarr and you would not give others your private key, so I would know that it was not signed by dominic, but by a new author, and that could be raised as a issue. The same thing happends with SSH, first time you connect to a server it generates a host key, if the ip of the server suddenly change, you have to explicitly regenerate the host again to be allowed to connect to it again. It does that so you don't connect to random servers if they were hacked. > The malicious package was published under the name of a trusted author already. The publishing rights were moved, but the new author was not a trusted author. The npm publishing model is not based on trust but based on permissions. > This isn't particularly scalable. It's hard enough as it is to get other people to even review the source of your open source library; asking them to stake their reputation on signing it too would be an even higher bar. Very few packages would end up cross-signed like this. Yes, but you could put a price on people verifying packages for you, you could make an incentive for people to verify. This is like reviews on Foursquare and all these things, were people make their buying decisions based on reviews.