Some background: I’m a software developer, and I’ve never really participated in the open source software community before. (i.e. I don’t contribute to open source projects, I don’t know anyone who does, and I don’t really know anything about the companies who start these projects to begin with, or what their motivations are for being open source.)

I’m currently trying to find software that my team at work can use to solve a particular problem we have. After doing some googling, it looks like this open source product called OpenReplay is a good fit for what we need: https://openreplay.com/

But when I first visited that website, I noticed that the background artwork looks AI generated. This made me feel skeptical of the project, and it makes me wonder: what if it’s actually a huge scam and it’s actually malware? For example, maybe OpenReplay is actually a copy of a different legitimate product that I’m not aware of. Maybe all of the stars, forks, and discussions on the GitHub page are from fake accounts. When I Google OpenReplay, there aren’t a whole lot of results. How do I know if it’s trustworthy if I can’t find an authoritative source telling me it is?

Maybe I’m just being paranoid. But this is basically the first time in my career where I’ve tried to vet a new piece of software for my team to use, and I want to make sure I’m doing it right. How do you know when a product like this can be trusted?

EDIT: I don’t mean to cast doubt on OpenReplay specifically, I’m just using that as an example because it’s the product I’m currently looking into. My question applies to any piece of software that isn’t widely known about.

  • Maybe all of the stars, forks, and discussions on the GitHub page are from fake accounts

    All 9k stars, 10k PRs, 400 forks & professional web site are fake? Come on this is about the most obviously not fake project I’ve seen!

    How do you know when a product like this can be trusted?

    The same way you tell if anything can be trusted - you look at the signals and see if they are suss. In this case:

    • Lots of stars
    • Lots of real code in the repo
    • Professional looking website with commercial pricing
    • Lots of issues
    • Good English

    The amount of effort it would take to fake this for very little benefit is enormous.

    Maybe I’m just being paranoid.

    Yeah just a little!

    •  sus   ( @sus@programming.dev ) 
      link
      fedilink
      16
      edit-2
      1 month ago

      All 9k stars, 10k PRs, 400 forks & professional web site are fake?

      Technically, it is entirely possible to find a real existing project, make a carbon copy of the website (there are automated tools to accomplish this), then have a massive amount of bots give 9K stars and make a lot of PRs, issues and forks (bonus points if these are also copies of actual existing issues/PRs) and generate a fake commit history (this should be entirely possible with git), a bunch of releases could be quickly generated too. Though you would probably be able to notice pretty quickly that timestamps don’t match since I don’t think github features like issues can have fake timestamps (unlike git)

      though I don’t think this has ever actually been done, there are services that claim to sell not only stars but issues, pull requests and forks too. Though assuming the service is not just a scam in itself, any cursory look at the contents of the issues etc would probably give away that they are AI generated

    • I agree it does look legitimate, I was just wondering what signs I should look out for in general. Like I’m sure fake GitHub engagement must be a thing, but I don’t know how widespread it is and I don’t know what the threshold is before a project can be considered definitely real. It sounds like you’re saying the level of engagement on this project is well beyond what can be considered sketchy, which is helpful information. Thanks

    • There has been instances of popular and well meaning projects become hijacked by hostile actors. A recent notable example is xz, but there’s also event-stream npm package a few years ago that got infected with Bitcoin stealing code.

      Just because a protect looks good now doesn’t mean it won’t turn bad in the future.

      And not only would you need to audit the project. You also need to audit all of its dependencies as well. The xz vulnerability made it in to SSH. Who would think about looking into xz for vulnerabilities?

      The amount of effort it would take to fake this for very little benefit is enormous.

      The benefit of installing back doors can be enormous.

      • A recent notable example is xz, but there’s also event-stream npm package a few years ago that got infected with Bitcoin stealing code.

        They’re asking if the entire project is somehow fake, not if it’s a real project that got backdoored. That’s obviously impossible to tell just based on stars, language quality, and similar heuristic signals.

  • First off, good on you for being careful. Ultimately, use the same methods that you would use when vetting other sources, like academic or personnel for hiring.

    Check reputation via stars, active contributors, see what accounts are contributing and what other projects they also contribute to. Check their LinkedIn profile and personal websites.

    See if you can confirm the project is being used safely by reputable groups. See if people, especially public people you trust are using/recommending it without being sponsored.

    Check in private forums with other devs and users, see what people are saying. Check the code yourself, etc.

    Ultimately, there’s no way to know 100%, even large companies and organizations have been duped in the past by backdoors or security bugs in OSS they use. You can be very confident however, it’s all about how much investigation you are interested in doing.

    And of course, don’t ever put all your eggs in one basket.

    And if after lots of investigation, you still have a bad feeling in your gut, listen to that. Better to be a little too careful than to compromise yourself by ignoring that gut feeling that something just doesn’t pass the smell test.

  • I think open source software has the huge advantage of being auditable. I suggest you and your team audit the entire code to see if anything is harshly wrong in there or you rely on other people doing it with you.

    We actually dont know how many backdoors are in proprietary software and we never will until all code is finally forced into the open as it should be.

  • The only surefire way is to read it all. And understand it all. That ain’t happening though. So you decide how much to do.

    You should figure out how many people are landing patches and get a rough sense of why. Same for folks filing issues or talking about the project in general. Maybe you trust one of the contributors for some reason. Either way, you want to know how alive the project is.

    You could land a patch.

    You could spot check parts of the code.

    You could run vulnerability scanners on it.

    I dunno. It’s hard.

      • It’s not a big red flag, but it indicates that the product is not fully open source. You can get the full community edition from Github, but for the Self-hosted Enterprise version you have to contact sales.

        So all the Enterprise features are most likely closed source, and when you buy/license it, you’ll just get the compiled version. And since their Cloud hosting model has a “Per 1,000 sessions/mo” model, their Enterprise self hosted model might have that as well. So it’ll have some kinda DRM/License managing, and maybe a “call home” to check your license or usage every once in a while

        • The point of the license combination they use is to allow the enterprise version to be open and live in the same repo as everything else. Dunno if that’s what they do, but that’s why the elastic license exists.

  • I don’t think it’s a dumb question.

    Unfortunately I’m not sure there’s any guaranteed method to establish trustworthiness. It’s especially difficult because if there was, it would probably be easy for the scams to utilise and thus it would stop being a good method.

    Anyways, I would say try to look at the people behind the software - do they have personal websites or do they work on other stuff that also seems reliable? What about the users, do they seem legitimate? Are the issues actual issues, not fake ones? Does the code seem maintained on a regular basis with non-trivial commits? Can you find online third party mentions that seem trustworthy?

    That’s just what I could think of. But essentially, there is no silver bullet and you’ll just need to make a thorough assessment and decide if you trust it enough.

  • Basically the same as fake news. Check web articles and so on. (Reading source code is often infeasible.)

    You can also check Linux package managers. Official repositories from, eg, Red Hat and Suse are well maintained by the companies. I’d trust also the official Arch repo. I guess Debian is trustworthy, too, but don’t know the process there.

    Regarding OpenReplay, you could also check the companies listed as using OpenRepay. (I couldn’t find any official source from those companies that mentioned OpenReplay, but that’s rather expected given that they don’t have to open their software stack.)