The State of Projects
Old popular, and no longer maintained and forgotten projects can often be used as a vector to spread viruses if someone is able to compromise the account and upload a new compiled version. The same has often been done with automatic update systems - even worse as they'll deliver themselves and often install an update on the users' systems without the end user knowing.
Possible Actions to Take
Maintainers and Developers
You can try to contact the developer/maintainers(s) but if it's an old project it's unlikely that they will respond. If their account has been compromised then you'll be giving them a heads up or left shouting at a wall.
Platform / Delivery Network
You may have a better chance removing the malicious code by contacting the platform that is hosting the software. I myself haven't tried to directly contact a platform like Sourceforge or NPM. The likelihood that you receive a response back is often tied to the size of the business and if it has been monetized -- if it's a one person show then good luck!
The more information you have to verify your takedown request the more likely and speedily it should happen.
The Community & Your Voice
Often you may try the above steps and get here feeling powerless, but if you're able to leave a comment or review on the software that may be the best thing you can do. Even though many end users will still download the software blindly or previously trust the software.
Extra: Recently & Future Prevention
Stop Reading Here™ or Continue
There was a highly used NPM package that the original maintainer was done with - as many open source projects reach in their life cycle. Someone reached out asking to maintain it. Surely this must feel like a nagging burden lifted from a developer's shoulders. Unfortunately the new maintainer released malware to steal crypto wallets.
Ironically I heard about this through word of mouth and reading the issue opened on the github repository before reading an article about it or seeing it show up in the
npm audit. This goes to show that your voice on a public platform really can have an impact.
Our meetup group had a quick talk around what the community could do to prevent such a thing, and whose responsibility it is to prevent such from happening.
Platform / Delivery Network
Making it npm's responsibility would require a monetized situation in place which would suck, or maybe it would only be available to businesses - but then everyone else would benefit for free?
As open source maintainers we need to be mindful of the consequences of our actions. If you've been an open source maintainer it can become a chore as your intrinsic value you get from the project diminishes. It would be hard to say no to someone that seemingly has the energy you once had to keep your project moving forward. One thing to note is that some platforms allow for a review process before publishing if the correct permission levels are in place. In this instance the project's ownership was completely handed over, you should try not to do this unless you absolutely trust the person/entity - even still this feels like it's not a clean way of conducting the continuation of software that has been established and trusted. People could also make their on forks of code but then that can get messy. Sometimes the best course of action is to archive a project, deprecate it and try to move users towards a new library/project instead.
Community & Consumers
Current infrastructure could use some features to help out.
For instance releases could be verified, approved, or flagged by the community, just like how torrents can be rated up or down by the community so others can make quick decisions before they take the plunge. A high negative rating could flag a package and warn consumers about it and future installs.
As a consumer who blindly installs software and updates to it, it is your responsibility to watch what you're consuming. You can use package managers that have version locking in place to help negate this. Unfortunately I doubt many people spend the time required to review the 100's of packages they're installing when they lay down a good'ol
npm install. Some businesses go through a vendor process when software changes; I would hope no business does this for NPM packages (it could seriously halt development), but this was an option brought up.
Nobody wants to pay for free open source software, but if those who were writing code were rewarded for their contributions they may be more motivated to maintain their software and community image. Money could come directly from the consumers or as a trickle down for the platform it's being delivered on. As much as I would hate to see it, I could see libraries following the same path as CI platforms - free for open source but cost for private/business - this could be handled with licensing, but developers don't want to waste time becoming licencing professions either (maybe they could be simplified and straight forward).