[skydhash]

> I can assure you that numerous new users would simply look through MELPA and pick up packages that sound useful, and quickly end up picking up malware

But the issue is not new users picking up unconfirmed packages. It’s about active employees getting compromised by extensions they trusted. As the nature of packages update is opaque and the default settings leave you vulnerable.

If you go on magit’s page on melpa, you get the commit id used for the build and if you wanted too, you could diff the files with upstream. Everything is transparent. Meanwhile what you got on marketplace is whatever is pushed by a token.

And another nice thing about packaging system like emacs is that they rely on peer dependencies instead of pulling their own from the internet. Which is nice, because when a bug is patched, you update that single dependency and you’re done. No need to update every package that depends on it.

[0]: https://melpa.org/#/magit

[simiones]

Transparent doesn't mean secure. The very source of this issue was a recent NPM supply-chain attack, and you can also check the sources of any NPM package that you use. NPM also relies on peer dependencies, and this is exactly why malware spreads so efficiently in the ecosystem - just like it helps spread bug fixes, it also helps spread malware as efficiently.

Very, very few people, even in tech circles, check the sources of all of their dependencies. Sure, compromising magit's sources will be hard - but you don't need to compromise magit. Just compromise one of magit's dependencies and watch the malware spread.

Edit: in fact, you don't even need to compromise Magit's dependencies. Since the developers of Magit probably use Emacs themselves, you can probably just compromise some small Emacs package that happens to be used by someone on the Magit team, get access to their repo from there, and then you actually may be able to compromise Magit itself (depending on how strict their code review etc rules are).