What's going on with Moq? SponsorLink and burnt soil!


The famous Moq library faced some criticism due to the usage of SponsorLink. What is the problem, and what is going on here? And obviously, I will add all the sources to the articles.

I will quote here the official GitHub repository of SponsorLink:

Integrate GitHub Sponsors into your libraries so that users can be properly linked to their sponsorship to unlock features or simply get the recognition they deserve for supporting your project.

Basically, it is a .NET analyzer that hooks into your build process and checks if the user has a GitHub sponsor for the given project. If not, it will show a warning. Otherwise, it does not. I will not discuss here whether or not this is a valid approach or not. Financing open-source development is a complex topics where there is no single solution to the problem. I do understand the reasons, though. Do you remember the log4j vulnerability? Big companies are using open-source libraries without giving anything back.

Anyway, back on track, the issue in this concrete example is the following:

Specifically, the actual email is never sent when performing the sponsoring check. The email on your local machine is hashed with SHA256, then Base62-encoded. The resulting opaque string (which shoul never reveal the originating email) is the only thing used.


The problem here is that you can not opt out of the process. Furthermore, the data is sent to a cloud server. The article is from the creator of the library itself - it also describes a bit more in detail what is going on. There might also be a GDPR compliance issues here. Yes, the data is hashed and encoded, but it is still sent to a cloud server without your explicit consent. Furthermore, there is no mechanism for you to delete your individual data from those servers. I am no lawyer, so take that with a grain of salt. All in all for corporate projects, this might be a no-go.

German courts ruled that SHA-256 is not suitable for anonymising personal data.Source

Also SponsorLink is completely closed source - you can not see what is going on and either trust the author or try to find out with tools like Fiddler what is going on behind the scenes. It clashes with the philosophy of open source. And yes of course you could argue that you can just not use the library or don't see it so black and white, but I am not sure how that helps the discussion or the underlying problem.

There are other technical concerns: SponsorLink delays your build time as it has to gather information and check stuff on a cloud service - and if you are not donating, you get a build warning. I am someone that always enables TreatWarningsAsErrors. So this will fail and delay your build and build server (EDIT correction: Build server are not facing this issue as SponsorLink checks if you are in an editor or not - hopefully no false positives here).


Now full circle back to Moq. Moq introduced SponsorLink in 4.20 of the library with the following Pull Request. Now the problem here is that without any further notice, from one day to another, the library started to send data to a cloud server. One day to another, you might not be GDPR compliant. For completeness with 4.20.1 the creator of Moq removed SponsorLink again, but the damage was already done. And it raises another question once again: How trustworthy is the library in the future? Will it be added again? Will it be added to other libraries? Also the dependencies of your library could, in one way or another, have dependencies on SponsorLink and you might not even know about it. Side knowledge: The creator of Moq is also the creator of SponsorLink.

With the nature of SponsorLink you are opening yourself to supply chain attacks as you can not control what is going on on the other end of the wire!

My personal bit

Don't get me wrong, Moq was and is an awesome library. Personally, I will also find alternatives, as I used Moq a lot in my projects. It is hard to see, as an open-source developer myself, what drastic measures are taken - but I also understand the dire situation. Moq only has very few sponsors but has multiple 100 million downloads! Way outs include just taking another mocking library or writing fakes on your own and be independent of any library.

Personally, I don't expect any money for any of the libraries I maintain (like bUnit). I do sponsor some libraries on my own. But these are just my personal thoughts on the topic. And I do know that everyone sees that a bit differently and invests more or less time.

There is also a whole discussion ongoing on the Moq-GitHub repository.


As this is a hot topic right now, me and other people shared their bit on social media like LinkedIn (or this blog). And I want to address some of the thoughts I feel important to address from my side. One general theme I often get is, that if you don't like it, don't use it. Where this is absolutely a legitimate way of dealing with the situation, I don't feel that generalized, this is a way forward. Discussion and constructive feedback is important. Being able to talk about potential issues should always be allowed. It is somewhat part of the deal if you do "public" work.

I also read that this is "perfect for content creators" as we (I include myself here) can use such stories for reach, likes and whatnot. And yes, that can happen. But with that, every news channel can just stop broadcasting. I still believe it is the right call to talk and write about the issue. Especially as it can have implications for everyone.

But that does not mean that blaming is the right direction. Far from that - I don't feel one should blame kzu. For him, it was, presumably, the right call to make. And I am also pretty certain that he was not aware of GDPR implications in Europe. And I also don't feel that the majority of people are destructive - at least what I read on Moq's official issue tracker.

So where do we go from here? What should we do with the situation? Well for starters everyone has to evaluate if (s)he can use Moq (again, the problematic bid was removed) and trust Moq in the future. Also, you could go to another library or create fakes by hand.

But broader it raises the two old questions of a) how and if open source projects should be funded. And b) how reliant we are on external dependencies. Personally, I saw a trend in myself to remove some of the packages in my private projects and somewhat reimplemented the functionalities I needed. Obviously, that doesn't work for every project and setting, and the time you have to spend writing and maintaining has to be put against the tradeoffs. And that has to be evaluated for every project by its own.

Update 10/08/2023

Kzu mentioned that he open sourced SponsorLink completely:

SponsorLink is OSS now. You can inspect the code and hopefully I've done quite a bit of work to ensure the impact on build is absolutely minimal. There may be further improvements to make (such as checking all-local) though.


He addresses the issue, I guess, because of the announcement of version v4.20.2 of Moq:

NOTE: in addition, there were potential privacy issues raised with regards to the SHA256 hashing of user' email to check for sponsorship, so it won't be coming back until that's properly addressed

So SponsorLink will become sooner or later part of Moq again. I, personally, don't think that should be the way forward even if it does comply with GDPR laws or rules. It seems the move or the public coverage brought some mixed output. There is a huge change in the sponsorship of moq itself. Also noticeable here.

Using GitHub as your portfolio

GitHub is a powerful platform for developers to showcase their work and projects. It can be an excellent tool for landing a job, as many employers use it to search for and review potential candidates. In this post, we'll discuss how to effectively use GitHub as a portfolio to impress potential employers and increase your chances of getting hired.

Creating Your Own Fakes Instead of Using Mocking Libraries

With respect to the current topic around Moq, I want to showcase how you can easily roll out your own fakes so that you are not depending on a third party library.¨

From Zero to Production - Generate everything with a single button

This blog post will show you how to setup, from scratch, your GitHub repository so you can in a matter of a single click:

  • Run tests and build your application
  • Release the application for example to nuget
  • Create a Release on GitHub with Release notes
  • Update the documentation utilizing GitHub Pages and DocFx

Therefore we will build a "template" repository you can take as a foundation.

An error has occurred. This application may no longer respond until reloaded. Reload x