The registries can't do much beyond enforcing better auth for uploading packages. Forced 2fa will help a lot.

Almost every other action would be just an guess with information for the devs and getting in the way of edge cases. For example, what if you genuinely want to publish a malware example or a vulnerability reproducer? What if you want your own fork of another package because you carry extra patches?

▲

maxbond 9 hours ago | parent | next [-]

I can understand why there's a research interest in publishing malware but I don't understand why there would be in publishing it to a language's official package repository. If you want to experiment with repositories hosting malware for some innocent reason, configure your package manager to use a self hosted repository.

▲

viraptor 8 hours ago | parent [-]

Because it's general and public. Then again, how would you tell the difference apart from the description? For example this https://www.npmjs.com/package/@celo/encrypted-backup is just a few lines away from a ransomware system. This https://www.npmjs.com/package/web-vuln-scanner can be both offensive and defensive. It's mostly how you use them, so there's little chance for any system to detect with certainty went no false positives.

▲

maxbond 7 hours ago | parent [-]

An offensive tool is one thing but a piece of malware meant to act within the supply chain (either at build time or runtime) is a different story. You tell the difference by reading the code and finding eg a crypto stealer, like Socket did here.

▲

viraptor 2 hours ago | parent [-]

That reading the code doesn't scale. There's not enough people ready to read all the published packages and even if there were, that's still acting after the packages are published and potentially used. Also as more people start looking at this, the malicious functionality will be hidden better and split into fragments between dependent crates. Think one crate providing directory walking, another the patterns to match but commented as something genuine, another doing genuine network lookups, another tying it together in a nonobvious way in a macro that gets part of the behaviour initialised at runtime. We're only seeing the fairly trivial cases these days.

	▲	maxbond 2 hours ago \| parent [-]
		I don't disagree I just don't see how that contradicts anything I've said. I don't see why that would mean we should be okay with leaving a malicious package in the repository after we find out it's there, whether it's claimed to be research or not. We will struggle to read every release of every package and we won't catch every attack, though, I agree. If we were able to force adversaries to engage in sophisticated multi-pronged attacks instead of trivially malicious packages, that would be a win. It would make their operations more complex, time consuming, and prone to failure.

▲

vlovich123 9 hours ago | parent | prev [-]

These weren't account take over issues like plagued npm the last little while. This is just a vanilla library that you hope someone adds as a dependency and you attack the users of whoever runs the code. 2FA does nothing here.

	▲	viraptor 9 hours ago \| parent [-]
		I know, that's why the second paragraph. General, public repos can't solve this problem if they want to remain open to everyone. It's on the developers to deal with that side of the problem.