Today I found a GPLed project on SourceForge whose executables are spreading a virus. This fact has been pointed out several times in reviews of the project and the infected executable is still available for download. Apparently, older executables are not infected, so the project itself does not seem to be made with malicious purpose in mind. There is no preferred way to contact developers and forums for the project are dead. What should I do?
  • 2
    This question is on topic, but in the future, if you want to ask if a question is on-topic, please use the meta site
    – user8
    Sep 13 '10 at 16:52
  • 1
    Why wait before contacting SourceForge directly? Verify if it's a virus, then contact them right away. Sep 13 '10 at 17:56
  • 1
    Your edits made this question off topic / too localized. Programmers.SE is for subjective or extended discussion about topics concerning the majority of programmers, not for diagnosing virus scans.
    – user8
    Sep 13 '10 at 22:26
  • @Mark Trapp Yeah, I was thinking how to split this into two parts, one for general case and one for this specific case. The second part can be considered off-topic.
    – AndrejaKo
    Sep 13 '10 at 22:32

If you can't get in touch with the developers, then contact SourceForge. Report the problem, give them detailed information they can use to verify the issue, and they'll (probably) take it down. They're a reputable site and I imagine they wouldn't want to be associated with malware.

  • Hey Mason, What do you think about the fact that inbetween when you posted this question and today, SourceForge's reputation has both plummeted and ownership has changed hands (and this SourceForge has potentially had its reputation slowly climb back up)? Should this answer reflect the fact that when people actually asked SourceForge to do something about it, they didn't do anything, and at times, it was SourceForge itself who was responsible for delivering these viruses, either through ads, or through its own intent?
    – Krupip
    Jan 14 '19 at 14:33
  • @opa Wow, yeah, this is an answer that hasn't aged well... Jan 14 '19 at 16:27

I would start by sending an email to the project maintainer and developers.


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?

Source Maintainer

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.

Money $$$

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.