Privacy concerns regarding Moq library in Hangfire

[todorovicg]

Hi,

This isn't really an issue, but rather a concern.
I am writing to discuss a concern regarding the recent changes introduced in the Moq library, specifically starting from version 4.20.x.
This library is used in Hangfire as well.

After 4.20.x changes, library has exhibited behavior similar to malware (or spyware), collecting and sending unauthorized (apparently hashed) emails from Git to external cloud services. This, of course, is done without any knowledge of a consumer where a potentially malicious code will execute after "quiet period" ends.

This may pose a significant privacy risk for this library and it's contributors and therefore I'd like to propose to author of Hangfire to find an alternative as a long term solution. There are a couple of libraries that similar to Moq like NSubstitute for example.

One of the short-term solutions is to remain on version 4.18.4 and below which was proven to be safe and clean.

Sources:
https://github.com/moq/moq/issues/1370
https://github.com/moq/moq/issues/1372
https://www.bleepingcomputer.com/news/security/popular-open-source-project-moq-criticized-for-quietly-collecting-data/

[odinserj]

Thanks for the hint, Hangfire uses Moq only in tests (so this issue doesn't present in any of its packages), and is currently using the 4.10 version of Moq that's free from this problem.

As I understand from the issues referenced, the package itself was not compromised, and the author of Moq library made these changes just to found some new ways of sponsoring his work. I agree that this is not a correct way to access and send personal data or its derivatives, and will consider switching to another package if these changes will not be rolled back in the near future to avoid any problems if Moq will be upgraded by an accident.

I believe these changes will be rolled back given the overall reaction on this topic, but let's wait and see.

[karl-sjogren]

It has been rolled back for now (due to build problems on OSX and Linux if you referenced the afflicted package versions, not because of the backlash) but he has stated that he will bring it back in the future without exfiltrating personal data. But it also had other problems such as artificially slowing down the build for non-sponsors which is a slippery slope to doing other nasty things.

So in my opinion this isn't a technical or privacy related problem any more, it is a trust problem that you don't know how or when a new "solution" is introduced.

But as I said above, the change is rolled back for now and the problematic versions are even unlisted on nuget.org so in the short term this isn't a problem.

[Joe4evr]

Hangfire uses Moq only in tests

Well, of course, it's always been a tool just for tests. I don't know why anyone would ship Moq with their end-product. The problem is that it would have been exfiltrating data from your developers.

I believe these changes will be rolled back given the overall reaction on this topic, but let's wait and see.

It's already been rolled back now, not because of the privacy backlash but because it wasn't working on macOS/Linux, and Moq's maintainer refuses to promise it won't come back again.

currently using the 4.10 version of Moq that's free from this problem.

I'd highly recommend at least putting a comment at the <PackageReference> stating its version should not be updated because of the broken trust so this won't slip through the cracks.

[odinserj]

Well, of course, it's always been a tool just for tests. I don't know why anyone would ship Moq with their end-product. The problem is that it would have been exfiltrating data from your developers.

Yes, I understand, that's why I'm willing to replace the package if the issue persists.

It's already been rolled back now, not because of the privacy backlash but because it wasn't working on macOS/Linux, and Moq's maintainer refuses to promise it won't come back again.

Yes, that's why I didn't close the issue – and waiting for some resolution from the author.

I'd highly recommend at least putting a comment at the stating its version should not be updated because of the broken trust so this won't slip through the cracks.

This is a really nice hint, thank you for it!

[todorovicg]

You cloud also add a constraint to limit the package version number along with the comment. This will keep the package on fixed version and prevent any accidental upgrades
For example:
<PackageReference Include="Moq" Version="[4.10.0]" />

[odinserj]

You cloud also add a constraint to limit the package version number along with the comment. This will keep the package on fixed version and prevent any accidental upgrades

As far as I understand, [4.10.0] is the same as 4.10.0, since in both cases we specify explicit version (unlike when using a placeholder like 4.*). Am I wrong?

[todorovicg]

Hm, you're right! Since it's an exact (strict) version in PackageReference it will behave the same. For floating versions it's another story.