Warnings with latest version from SponsorLink

[GeorgDangl]

Hey team,

I appreciate the effort, and really like Moq, thank you for creating it!

In one project, I just did a dependency update and noticed that I get MOQ101 warnings when building in Visual Studio, along with a behavior that seems to block the build for a few hundred milliseconds:

It looks like this was introduced in in https://github.com/moq/moq/releases/tag/v4.20.0 with #1363.

Is there a way to disable the warnings, e.g. via a setting in the *.csproj file of the test projects or similar?

[njannink]

I tried to suppress the warning using

<NoWarn>$(NoWarn);MOQ101</NoWarn>

But then I get the following empty warning.

If this SponsorLink is going to be a requirement then Moq will no longer will pass our acceptance criterea. Our company GDPR rules won't allow leaking all developer internal email addresses, meaning we will be forced to switch an alternative mocking framework.

[DanielCordell]

I'm likely in the same boat. I've made an issue on the sponsorlink repo too highlighting some potential issues, devlooped/SponsorLink#16, but I'd hate to have projects basically become unusable in company environments over something like this, which I really do believe is a genuinely noble thing.

[Aculeo]

This is just unacceptable, free or not. It is not even mentioned on the release notes. Suddenly having a proprietary blob DLL added that sends data to a cloud service is big no and we will avoid Moq in the future.

[martincostello]

The MSBuild target in this GitHub gist may work around the issue with 4.20.0 and 4.20.1 (I'm not conclusive of that from my experimentation in Visual Studio, and given caveat emptor) until a solution that's broadly acceptable to the community is reached.

I'm supportive of Moq getting sponsorship for the value it brings, but the implementation added here is disruptive and raises privacy concerns, particularly for non-corporate sponsored usage of Moq in other FOSS.

[girlpunk]

Additionally, the library being used to do this has now licence. As such, Moq will be unusable for most (if not all) business/commercial uses.

[Atulin]

Some deeper discussion in #1372. As it turns out, SponsorLink also gets it's config from a remote location, and hides itself for the first few days...

[zarlo]

Some deeper discussion in #1372. As it turns out, SponsorLink also gets it's config from a remote location, and hides itself for the first few days...

so just like a virus

[dmsch]

Malware in a dependency is in no way acceptable.

[kzu]

Heya folks: added a note to get you at ease with this change: https://github.com/devlooped/SponsorLink/blob/main/readme.md#privacy-considerations

At no point is the email sent to anyone, unless you EXPLICITLY authorize so on GitHub itself.

Would making the SponsorLink analyzer itself opensource change things at all? Also, wouldn't
that defeat the purpose of the check if people just saw how it's performed and simply bypass
it?

NOTE: there is NOTHING done on CLI / CI, there is no run-time dependency, it's just an IDE
feature.

[jameshilliard]

Would making the SponsorLink analyzer itself opensource change things at all?

Dependencies that can't be easily audited are inherently a security risk, especially when they have the ability to perform network communications.

Also, wouldn't that defeat the purpose of the check if people just saw how it's performed and simply bypass it?

Can't it already be bypassed by doing something like #1373?

it's just an IDE feature

Potentially compromising an IDE is still a significant security risk.

[Atulin]

At no point is the email sent to anyone, unless you EXPLICITLY authorize so on GitHub itself.

NOTE: there is NOTHING done on CLI / CI, there is no run-time dependency, it's just an IDE feature.

Source: trust me bro

[Aculeo]

It doesn't really solve the problem though: we can only trust that the DLL is safe and works as advertised.

• Outside of behavior analysis or arduously taking it apart through decompilation (hard to do with obfuscation) there is no way to be sure. This is a massive security risk.
• it is completely unexpected behavior when installing a mocking library. I don't expect such a library to perform network calls or run my Git executable. I don't know what else it does. Who knows what potential new security issues that opens up.
• raising build warnings is rather unexpected and will undoubtedly break some builds in the future, in lots of environments warnings are treated as errors.

And all of this just to nag developers to sponsor the library? It is unfortunate that so many companies don't contribute back to open source libraries, that should definitely change, but this is not the solution.

[GeorgDangl]

Heya folks: added a note to get you at ease with this change: https://github.com/devlooped/SponsorLink/blob/main/readme.md#privacy-considerations

At no point is the email sent to anyone, unless you EXPLICITLY authorize so on GitHub itself.

Would making the SponsorLink analyzer itself opensource change things at all? Also, wouldn't that defeat the purpose of the check if people just saw how it's performed and simply bypass it?

NOTE: there is NOTHING done on CLI / CI, there is no run-time dependency, it's just an IDE feature.

Hey @kzu, thank you for the reply!

I was very surprised yesterday when I noticed that new behavior. As I said, I get your reasoning for this, but I think it went way too far. With just doing a package upgrade, there was suddenly code running during build time that analyzed my local computers configuration. Additionally, it seems that there are web requests being sent to a command & control server. This, combined with the fact that SponsorLink is not only closed source but even obfuscated, makes it just look very untrustworthy.

Analyzers are supposed to locally analyze the code, as @sharwell made you aware of in April: devlooped/SponsorLink#10

I can not imagine a scenario where any company would allow such a behavior.

Personally, I don't believe there was malicious intent on your side, but the whole behavior is so close to malware. And, additionally, we're introducing a whole new attack vector by allowing SponsorLink outside communication during build times.