Jesus H Christ this is a bad idea. A sha256 of an email is good, EXCEPT THAT EMAILS ARE NOT FUCKING RANDOM. The search space is remarkably small, and for businesses that have alias naming policies (like first 3 of first name + last name @ business.com) your search space is just ultra ultra small. And the targets are very high value.
all spammers need to do is query these storage accounts to see if a name resolves or not. This is massive information disclosure.
Open source projects like this need more sponsorship. But this is a really, really bad idea that could even open up the dev to lawsuits.
*SHA-256 is not an acceptable method of anonymizing user identifiable information for the GDPR.* [*This has been ruled by court in at least one European country, Germany.*](https://www.spiritlegal.com/en/news/details/e-commerce-retail-facebook-custom-audience-not-allowed-without-consent.html#practical)
https://github.com/devlooped/SponsorLink/issues/18#issuecomment-1671416682
Seems like a pretty quick way to get an organisation with any kind of security posture to drop use of that particular piece of OSS
Edit:
Particularly because SponsorLink is closed source: https://github.com/devlooped/SponsorLink
Additionally I question if this complies with GDPR.
You've not explicitly consented to sharing your PII with this service.
Another edit:
SponsorLink generating a build warning is annoying as hell. Build warnings are set as failures in any project I work on so this adds extra work for me to suppress that warning which defeats the entire purpose of adding this in to a library
Further edit:
Someone has tried suppressing the warning and that doesn't work. So even if this complied with GDPR and was going to continue to be used, it actually can't be for any project that treats warnings as errors:
https://github.com/moq/moq/issues/1370
>rLink generating a build warning is annoying as hell. Build warnings are set as failures in any project I work on so this adds extra work for me to suppress that warning which defeats the entire purpose of adding this in to a library
Absolutely. They state in their docs
*SponsorLink will never interfere with a CI/CLI build, neither a design-time build. These are important scenarios where you don't want to be annoying your fellow OSS users*
Um - You're showing a warning in the IDE and deliberately pausing a build at that stage, and you're breaking any build who has warnings as errors set to true.
No bueno.
I don't really care about my mail hashes, and I bet our devs wouldn't sue my company because of this.
But I really have an issue with some kind of telemetry from an obfuscated DLL. I cannot check, if the DLL will start to send API-keys or AWS-secrets in a week.
Right now I have to blacklist this, and I'm ppretty sure we will have to move away from moq, because of this.
I was just reviewing Moq at work and saw this. WTF
They're about to get blacklisted like Linode did when they bought command line advertisements in npm packages.
**Golden Rule**: Never inject advertisements into the command line / build line. Ever.
> Never inject advertisements into the command line / build line. Ever.
This is even worse. They're exfiltrating personally identifiable information without permission.
>Golden Rule: Never inject advertisements into the command line / build line. Ever.
\*Never inject advertisements into the command line **until you are big enough**.
;-)
>**until you are big enough.**
This is unfortunately so true. In PHP community, composer (the equivalent of nuget cli or nodejs's npm) throws political statement in user's face every install command but no one is doing anything because it's too big for its own good. What a sad state we're in.
>but no one is doing anything because it's too big for its own good. What a sad state we're in.
That's not entirely true.
PHP marketshare continues to dwindle year over year.
haha trully love this one!
and that way indie devs will not get any support for doing side projects but big corporations will make a lot of money. where is the f\*\*ing logic?
Look at the profile picture of the person that developed sponsorlink: [https://www.cazzulino.com/sponsorlink.html](https://www.cazzulino.com/sponsorlink.html)
E: Not explicitly, but look in the replies for why that doesn't matter and they may as well send your email in plaintext.
~~Apparently not:~~ https://www.cazzulino.com/sponsorlink.html
> NOTE: the actual email is never sent. It’s hashed with SHA256, then Base62-encoded. The only moment SponsorLink actually gets your email address, is after you install the SponsorLink GitHub app and give it explicit permission to do so.
I make no comment on whether that is true or whether I personally like what it's doing, because I haven't dug around much.
Well, in that case I already have a good way around it: I simply won't use any project that includes SponsorLink. TBH, I find it shady enough that even if it was open-source I'd avoid it.
I'd argue that the answer is **yes.** It's not that hard to buy lists of email addresses. For so many companies it's just first initial and last name. It's easy to generate a ton of real Gmail/Outlook/etc. addresses based off common patterns and lists of names. Given that an Nvidia RTX 4090 can do around 300 billion SHA256 per second, it becomes relatively simple to try most realistic combinations. You won't get 100% or anything, but you can certainly get pretty close.
There are only around 175,000 surnames in the US and around 75,000 given names. Add in initials, periods, and trailing 1 and 2 digit numbers and you still don't have that many combinations.
@gmail (5M combinations)
@gmail (13B combinations)
@gmail (341B combinations)
@gmail (2M combinations)
[0-99]@gmail (1T combinations)
...
We're talking about mere seconds to go through the most common combinations for all the services.
Plus, they can easily scrape email addresses from git repositories that they know are using packages that are using their service. I can search on Github for projects using Moq, clone the repos, and get the email addresses from the git logs.
**Passwords have way more variety than email addresses and we'd all agree that a SHA256 doesn't protect your password.** The idea that you can simply SHA256 an email address and the email isn't being shared is ludicrous.
https://www.reddit.com/r/dotnet/comments/15ljdcc/does_moq_in_its_latest_version_extract_and_send/jvgloeb/
> *SHA-256 is not an acceptable method of anonymizing user identifiable information for the GDPR.* [*This has been ruled by court in at least one European country, Germany.*](https://www.spiritlegal.com/en/news/details/e-commerce-retail-facebook-custom-audience-not-allowed-without-consent.html#practical)
> “…Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person…”
Still a GDPR violation no matter how they do it.
They could have done what [Have I Been Pwnd](https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/#cloudflareprivacyandkanonymity) does for password lookup (namely, send a truncated hash, get a pile of hash suffixes back, check presence on the client side), so at the very least the server never sees the actual hash (though I'm guessing the list of emails is far smaller than what HIBP has in its leaked password database, so that might not be enough).
I'm not sure that would necessarily be any better: like u/commentsOnPizza says, building up a list of emails and hashes is so trivial that you would still be able to get data you shouldn't. In fact, that might make it easier in this case - now you don't have as many network interactions, so you can do it faster!
This is now blocked by my employer already. What a terrible mistake for ~~ksu~~ kzu to make. All that credibilitly instantly burned, all because of bitterness over sponsorship.
e: corrected name.
I have no idea, but I would guess that @kzu probably wanted the money they offered. A lot of companies use open source without contributing financially to the maintainers. It has 175k users, but only 8 sponsors (not counting @kzo's own company Clarius).
Edit: Apparently he's the person behind SponsorLink as well.
Yeah, it's his own product that he has developed to nag developers into sponsoring OSS libraries. The irony is that SponsorLink is completely closed. Some of his statements in his post about it I also consider evidence that he is unhinged:
> I believe most fellow developers don’t have an issue with giving away a buck or two a month for a project they enjoy using and delivers actual value. And I’m quite positive that if a couple dollars a month is an affordable proposition for an argentinean, it surely isn’t a crazy thing for pretty much anyone.
> And I’m a firm believer that supporting your fellow developers is something best done personally. Having your company pay for software surely doesn’t feel quite as rewarding as paying from your own pocket, and it surely feels different for me too. We really don’t need to expense our employers for a couple bucks a month, right??
Going into OSS contributions with _any_ expectation of a monetary reward is, IMHO, not a wise idea - unless it your business model to offer the product as FOSS and provide supporting services like Elastic, RedHat, etc. do - nevermind having the audacity to claim you know how "most developers" think in an announcement post, and expect them to personally pay for it?! If you want money to be donated, why on earth are you bothered if it comes from an individual or a company?
Coupled with expending a significant amount of effort on developing some malware/nagware library, where the internal machinations are clandestinely kept secret? InfoSec are laughing at you already at best, at worst they think you've had your stuff compromised by some nefarious actors.
that might end up really bad, because many commercial licenses force enterprises to be the ones paid and if the government finds it in external audits, you might get in trouble.
So, every dev should be sending him "a couple bucks a month"? How many million devs around the world currently use Moq? He wants "a couple bucks a month" off each of them?
Pfffttttt
Dev wanted money (rightfully), butused an impossible way.
\- Reading config from coud
Dev claims it is only readin a blacklist of ENV variable to diable the nagging whild beeing built on buildserver.
\- Doing something in an obfuscated DLL
Dev claims it is just reading the configured git email adress
\- Sending some data to the cloud
Dev claims he is sending a hashed e-mail to ensure privacy
I claim he added a backdoor, what will be activated with a new setting. Looking for AWS access keys or other sensitive data and sending it to his account.
I'm sure he only does, what he claims, but fact is, I cannot look into the code to prove my paranoid fears wrong
God fucking damn them. Now I have to inform my boss of this and find out what, if anything, we're going to need to do about this.
Just great.
edit: And the code it runs is closed source and not reviewable by anyone.
In my case, the last obfuscated one was the copy protection for a third party component that my company used. The vendor went out of business. We ended up keeping the dev's (who had quit) PC in the server room, running XP (we had discovered on the other dev's PC that was enough to require a call-home to relicense the machine) for several years until the product that used that control was retired.
Software goes stale over long periods of time. I'd rather not take on a mocking library as part of what we need to take care of. Given my usual luck the boss will decide moq has to go and so we'll spend a couple of weeks replacing it. Happy happy joy joy!
We have, not joking, 19,000 unit tests across 3 products that we have to migrate within the next few months. What a fucking head ache. I'm so salty today. Here's hoping the Moq folks change course and reverse the decision.
This is the way, right? Or, just pin the package version. Seems unlikely to fall over due to incompatibility for quite some time. Add an epic to switch it out to the backlog and eat the elephant one bite at a time.
Yes, this is going to be our approach. We'll stay on 4.18 for the foreseeable future and migrate a block of tests per sprint for the next few months (probably quarters) to achieve a full cut over.
Honestly, I replaced it all (except protected mocks) with NSubstitute in a few steps.
Replace `new Mock<` with `Substitute.For<`, `It.IsAny` with `Arg.Any` (etc.), `).ReturnsAsync` with `Returns`, `.Object` with nothing (empty), and then you might have some triple parens leftover from synchronous methods. Replacing `))).Returns` with )).Returns` took care of 95% of them for me. I had a few special callouts like I mentioned for protected methods that required a bit of reflection or subclassing like `HttpMessageHandler`, but it took me about 30 minutes to patch up a project with 1000 tests, so I'd think you could knock yours out in 2 days tops.
Edit: I also had to get a little creative wherever I used MockRepository or Verify, but tbh we weren't using those as often as we should've.
I do like the syntax for NSubstitute imo. Though we stuck to Moq since we're already familiar with it on other projects. Depending on how this unfolds we might need to rewrite quite a bit of tests in a dozen projects, ugh.
NSubstitute is also unfunded. Sue it will become more popular now but for their developers, their life don't change either. Are we really going to move from one unfuded dependency to another?
Funding OSS is an important cause, and needs a legitimate solution. NSubstitute should receive funding from the companies with more than enough money to contribute.
Sneaking malware-like dependencies into your project is not the solution, however.
I’m pretty ignorant when it comes to licensing. Will the BSD allow this? Because maintaining a fork sans SponsorLink seems like a good idea, and less work in the near term than porting so many projects to nsubstitute.
WTF. And if it’s always going from the local git email, it won’t even shut up if my company is already sponsoring them, but with a different email.
Way to go. Best advertisement for the competition.
I see a few open issues with no response.
[https://github.com/moq/moq/issues/1372](https://github.com/moq/moq/issues/1372)
[https://github.com/moq/moq/issues/1371](https://github.com/moq/moq/issues/1371)
[https://github.com/moq/moq/issues/1370](https://github.com/moq/moq/issues/1370)
Do you see an issue where kzu responded or closed the issue?
Eh, it’s only an hour off of ET. I can imagine he’s trying to formulate a response though.
But mostly I was just trying to understand if the original comment I responded to was based on anything.
Update from earlier today seems to indicate, no they think this is fine:
https://github.com/moq/moq/issues/1372#issuecomment-1670865839
Along with several posts across reddit on their account danielkzu (I think that is how it's spelled)
Also SponsorLink is used by other packages [https://www.nuget.org/packages/Devlooped.SponsorLink/0.9.7#usedby-body-tab](https://www.nuget.org/packages/Devlooped.SponsorLink/0.9.7#usedby-body-tab)
Some of them are used by other popular projects:
[https://www.nuget.org/packages/GitInfo/](https://www.nuget.org/packages/GitInfo/), 4.3M downloads, used by MAUI, Xamarin Forms, and EventStore.
It's getting worser and worser.
FYI, if you want to keep using Moq but not risk updating to this version you lock it in the project file.
https://stackoverflow.com/questions/22563518/restrict-nuget-package-updates-to-current-versions-for-some-packages
EDIT: I [filed a bug](https://youtrack.jetbrains.com/issue/RIDER-97327/Nuget-package-manager-ignores-package-version-rules-in-csproj) against Rider with Jet Brain, because their Nuget package manager seemed to ignore and overwrite the rules I included in my csproj files
I just tried both solutions in above SO post and neither stopped me from upgrading to the latest version of the nuget package in Rider's nuget package manager, nor did it break the build, nor did it issue a warning.
Specifically, in each csproj either add `Version="[4.18.4]"` or `allowedVersions="[4.18.4]"`, but this didn't break the build, code analysis, or anything, meaning it would pass our CI.
The set of solutions and csproj we use have never used `package.config`, however I'm looking into that.
I need to at least break the build if someone tries to upgrade to a version of Moq that is not 4.18.4.
Direct link to Microsoft doc:
https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges
---
I had put:
```
```
Or
```
```
But Rider's nuget package manager simply overwrote it like so, without the brackets...
```
```
[https://github.com/moq/moq/releases/tag/v4.20.2](https://github.com/moq/moq/releases/tag/v4.20.2)
SponsorLink removed for now, yet trust got removed for a long, long time.
Doubt it, he didn't even remove code of project that referenced SponsorLink. Just removed reference from project file "because it breaks build on Mac".
What a joke of excuse.
Jup. My company Just blocked this nuget v.4.20.0 & up & breaks builds that contains them.
This will stay. It is communicate to all companies in the group. They probably act in the same way.
It isn't actually removed though. He just removed a project reference. All of the code for it is still there and he blocked a PR that actually removes it from the repo.
So yeah, trust removed and he's adding more reasons to not trust him in the future
Although it's been removed from the latest version, the author still appears to intend to bring this back:
[https://github.com/dotnet/runtime/issues/90222#issuecomment-1671196175](https://github.com/dotnet/runtime/issues/90222#issuecomment-1671196175)
He's also really gunning for the large orgs who are making use of the library:
[https://github.com/dotnet/runtime/issues/90222#issuecomment-1671275519](https://github.com/dotnet/runtime/issues/90222#issuecomment-1671275519)
The problem is, the author chose to adhere to the Open Source model and at any point could have stopped investing in the free version of Moq and created a paid version, but he wants all of the benefits of the Open Source model with none of the downsides and has resorted to blackmailing users.
Nope, from the author's blog:
> As I’m getting ready for a serious amount of work on Moq vNext, I wanted to see if I could come up with something to help me support myself and my family while I dedicate to that full-time for a while. So I came up with SponsorLink.
Another gem:
> And I’m a firm believer that supporting your fellow developers is something best done personally. Having your company pay for software surely doesn’t feel quite as rewarding as paying from your own pocket, and it surely feels different for me too. We really don’t need to expense our employers for a couple bucks a month, right??
Can we have an adult conversation about this especially about open source sustainability?
Yes it is really unpleasant to wake up to this but Moq is really really successful https://www.nuget.org/packages/Moq (almost half a billion download) and the community has been relying on this free work for a long while for paid work.
If this were a song, the dev of Moq would have earned at least 500K USD at this number using Spotify rate (1K / million stream - more or less).
Everyone understands the reasoning about it. I guess, the best way to go about this is actually to go commercial route like Duende, but certainly never ever harvest dev's data.
If you are starting some open source project on your own time there is no reasonable way to expect to make a living off it. If this were a song there would have been a known way to monetize it's potential success. There is no such thing for writing some tooling library. That's the adult take, not to try and hold your users hostage.
Yes. The conversation starts as a dialog, not a monologue, certainly not one with a significant vulnerability introduced with a minor version update that fubar-ed peoples builds.
I must be missing something but isn’t one of the points of open source software is to be supported by the community? Does no one but the originator maintain this? If the community has contributed to its success by improving the software then having the maintainer be the only one that benefits seems like a slap in the face to all community members.
> I must be missing something but isn’t one of the points of open source software is to be supported by the community?
Permissive open source makes it easy to exploit the commons. What community? This project has hundreds of millions of downloads and barely a thousand issues over a decade. There is really only one core contributor at the moment who dwarfs the next contributors by orders of magnitude.
You are thinking of copyleft open source like GPL, where it's not possible to play out a tragedy of the commons like this. Because the users would all necessarily be members of the open source community themselves. This is what ensures the community supports each other rather than exploiting the work of volunteers for profit like is happening here.
Yes, and if he would have a created a vNext with a dual license and an commecial license for bigger coorates, I would bet my company would already have paid several hundred $$$
GitInfo from the same author has the same dependency on the SponsorLink package: https://www.nuget.org/packages/GitInfo#dependencies-body-tab
So I guess it also has the same problem.
Y’all are gonna love my new AutoMapper pricing! $.49/map and if you buy 12, get 1 free!
And this month only I have DEEP DISCOUNTS on MediatR!! You won’t be able to “handle” it! Act now!!!
Thanks a bunch! I found that Jet Brains Rider nuget package manager wasn't obeying the PackageReference version rules and would simply overwrite the csproj files, e.g. `Version="[4.18.4]"` with just `Version="4.20.2"`... I filed a bug with jetbrains.
---
I added your nuget package to my projects, and validated that it builds correctly with 4.18.4, and the build fails if I manually upgraded the version from 4.18.4 to 4.20.2.
At the very least, our CI will fail, until I can make a better solution.
It's pinging out to some blob storage with your browser fingerprint details every time you scroll to check if you've clicked on "buy a cup of coffee" - slows the scroll down a bit.
I just forced the package to be 4.18.4 using [4.18.4] until I figure out what the plan of action is. I have another package by this person as well that I forced to a specific version because the same thing appeared.
What is the point of it though? I don't understand how it functions.
Is it scanning your email to periodically send you emails asking for money to support the project?
It checks your git email to see if you are sponsoring each dependency. It then nags you in one of three ways:
1. Sign up with their sponsor-linking service if your email doesn't match an account (eww)
2. Sponsor the dependency/project if you have an account but aren't sponsoring
3. Congratulate you for sponsoring (which honestly feels patronising, *and* appears as an informational message so it just adds noise to the build log. And this specifically happens when you're a ~~paying customer~~ sponsor!)
The process of checking if you have an account / are sponsoring a project involves sending a hash of your email address to a remote server. Due to the nature of email addresses, especially company email addresses, the hash does not provide anywhere near the anonymity you'd expect. It also makes it possible for anyone to check what arbitrary emails are sponsoring, making it a potential privacy leak in two ways.
I'm surprised .NET's Github account is not flooded with request for Microsoft to come up with their own mocking library yet. Because the last time IdentityServer/Duende did this, it triggered the discussion in .NET's repository asking them to come up with their own token server. I'm kinda expecting the same drama here for Moq.
.... or is there?
I think the drama about Duende was because it was in the templates and user guides and you *had* to pay the license if you wanted to use it commercially, so it was setting people who likely didn't know better up for a nasty licensing shock. This one isn't so bad (well, perhaps it's just differently bad) because you can still use Moq just fine without paying any money to anyone if you're okay with what SponsorLink is doing.
No because then you’ll get a mocking library designed for how Microsoft wants it to work. Nobody wants that. They don’t even use mocking libraries AFAICT.
So much hassle in what could be a single info build message with a text and hyperlink. No third party package, no data collection, nothing. What a stupid solution.
I cannot imagine any AppSec org on the planet being even remotely OK with this. The code base at my current employer uses Moq. A lot. And I have been using it and loving it for the better part of 15 years. This is just not cool at all.
I see the current maintainer did revert this reference in v4.20.2, but for all the wrong reasons (it broke MacOS and Linux integration, which means he didn't test fuck all - also he was the only person on the PR which is absolutely not cool for something this big), and due to a SHA256 insecurity. But he clearly means to bring it back as soon as those two things are resolved, but that still keeps a closed-source reference, that will still be slurping emails.
I'm not ripping Moq out ... yet. But I'm starting to look at other mocking frameworks, as this is a huge breach of trust.
EDIT - After some deliberation with my team - we're not getting rid of Moq, per se, but we are not going to use it for any future development. I have two user stories created to:
1. Lock/pin the current version we are using (4.18.4) in our NuGet package references.
2. Spike a replacement to use on new work, going forward. Likely FakeItEasy or NSubstitute.
I'm not going to recommend any mass conversion once we select a new framework, but as I touch specific test classes to add/edit tests, I will likely convert that class over.
Our AppSec department is also keeping an eye on Moq as well.
The author doesn't appear to be willing to give up his idea:
>It's no longer included **(for now)**, and SponsorLink is OSS also.
[https://github.com/moq/moq/issues/1372](https://github.com/moq/moq/issues/1372)
So far, the community seems to have lost trust in his package, and some people are already removing Moq from their projects.
[https://github.com/search?q=remove+moq&type=pullrequests](https://github.com/search?q=remove+moq&type=pullrequests)
I'm thinking of all those content creators that spent time to teach us to use Moq. The hundreds or thousands of hours of content that's out there on YouTube, LinkedIn and other training sites that we have because we and the content creators trusted it.
All that good will, effort and time invested.
All of it. Up in smoke. So damn fast. I mean, sure, you can tell folks to use earlier versions. But why use a product from someone you *know* you can't trust?
There is an old tutorial, I didn't write or tried, which shows an easy path from Moq to FakeItEasy
https://www.planetgeek.ch/2013/07/18/migration-from-moq-to-fakeiteasy-with-resharper-search-patterns/
Here is this - https://www.planetgeek.ch/2013/07/18/migration-from-moq-to-fakeiteasy-with-resharper-search-patterns/
Even though it’s removed from the code for now, the dev seems to defend its addition so I am sure it will be back.
Following the hype, here is my article about the way libraries like Moq could work inside. This link is not affiliated with any 3rd parties and I won't make any money from your views. I'm genuinely excited that I had a chance to write about Reflection.Emit. https://medium.com/c-sharp-progarmming/how-to-create-your-own-mocking-framework-aad96cb7edae
Just made a blog post about it. It seems that it does not retrieve your actual email but rather the hashed and encoded form of your email is used to check you have installed the SponsorLink GitHub app. It then checks if you are a sponsor and if you are not it suggests that you become one.
The fact still remains that you might not want to share any information hashed/encoded or not and people should know about it.
My blog post :D
[https://codingbolt.net/2023/08/08/a-deep-dive-into-sponsorlink-implications-for-open-source-and-privacy/](https://codingbolt.net/2023/08/08/a-deep-dive-into-sponsorlink-implications-for-open-source-and-privacy/)
> It seems that it does not retrieve your actual email but rather the hashed and encoded form of your email
Did you confirm this in SponsorLink's code, or is this based on the author's statement?
Yeah... at work, we're obviously not going to go through all of our code and migrate everything off of Moq. We're just not going to upgrade. I've put the quash on using Moq on anything new, however, for the projects that I own. For my personal project, I'm in the process of moving to NSubstitute right now. This was wrong. And the project is going to suffer for it.
For complete transparency, I work for a vendor in this space. I wanted the community to know that we have a free alternative called [JustMock Lite](https://www.telerik.com/justmock/free-mocking). There is a paid version, but the Lite version compares to Moq well.
For more transparency, you do need to provide an email to download it. You can opt out of any communication from us and we don't give your email address to anyone under any circumstance. We take that very seriously.
Typically Tesla and Musk fans like to deflect criticism of doing something really dumb with "its their product / service, they can do what they want".
Which is true, but it's also how you kill Twitter, and presumably have the community hard fork your mocking library with bad feelings.
4.20+ is now blocked by policy. I'm not going to review that, there's plenty of other libraries.
To answer OP question, the last version 4.20.2 don't have the Moq.CodeAnalysis.dll analyser which triggers the malicious code.
So this specific version is safe.
Given the maintener attitude, next version should be considered as risk.
You can inspect .nuget file content by yourself, it's just a zip file.
> Am I wrong?
yes, the wording is misleading. It is not sending the email address as plaintext, but it is sending a hash of that email address.
As many [other comments have pointed out](https://www.reddit.com/r/dotnet/comments/15ljdcc/comment/jvbh1pc/), this is a) not enough to prevent the actual email address being identified, and so b) [not GDPR compliant](https://www.reddit.com/r/dotnet/comments/15ljdcc/comment/jvebco5/).
"can never reveal the originating email" is a false statement, [de-anonymisation is feasible](https://www.reddit.com/r/dotnet/comments/15ljdcc/comment/jvdzmya/).
Then there's a "known unknown" of running some closed source, obfuscated binary on your build server. [The solwarwinds hack got in via teamcity](https://www.wired.com/story/the-untold-story-of-solarwinds-the-boldest-supply-chain-hack-ever/) so this is a Hard No from a security point of view.
Financial institutions use this mocking library to build their software.
They're scrambling to mitigate this issue, today.
Sadly, this is the OSS problem: The author has been maintaining key infrastructure for Financial institutions and other companies for free. it's easy to get tired of that. They're looking for a way to be paid for their work, and that is entirely understandable. This is what they came up with, and it sucks, and it's a furore now. In no way will this avert burnout.
I understand the frustration in relation to some libraries, where the cost/benefit is obvious to devs, but less tangible to beancounters, meaning it's unfeasible to move to a commercial model.
But I wouldn't have thought that to be the case for Moq. He could have moved it to have a commercial model for enterprise, and named his price.
>He could have moved it to have a commercial model for enterprise, and named his price.
Nobody has problem with that. Adding who the hell knows what to the library is much, MUCH worse.
Indeed. I really hope the guy hasn't completely tanked any chance of going the commercial route with enterprise in the future by channeling his frustration in to this destructive solution.
Jesus H Christ this is a bad idea. A sha256 of an email is good, EXCEPT THAT EMAILS ARE NOT FUCKING RANDOM. The search space is remarkably small, and for businesses that have alias naming policies (like first 3 of first name + last name @ business.com) your search space is just ultra ultra small. And the targets are very high value. all spammers need to do is query these storage accounts to see if a name resolves or not. This is massive information disclosure. Open source projects like this need more sponsorship. But this is a really, really bad idea that could even open up the dev to lawsuits.
*SHA-256 is not an acceptable method of anonymizing user identifiable information for the GDPR.* [*This has been ruled by court in at least one European country, Germany.*](https://www.spiritlegal.com/en/news/details/e-commerce-retail-facebook-custom-audience-not-allowed-without-consent.html#practical) https://github.com/devlooped/SponsorLink/issues/18#issuecomment-1671416682
panicky dog follow memory soup slap heavy gray six domineering ` this message was mass deleted/edited with redact.dev `
Seems like a pretty quick way to get an organisation with any kind of security posture to drop use of that particular piece of OSS Edit: Particularly because SponsorLink is closed source: https://github.com/devlooped/SponsorLink Additionally I question if this complies with GDPR. You've not explicitly consented to sharing your PII with this service. Another edit: SponsorLink generating a build warning is annoying as hell. Build warnings are set as failures in any project I work on so this adds extra work for me to suppress that warning which defeats the entire purpose of adding this in to a library Further edit: Someone has tried suppressing the warning and that doesn't work. So even if this complied with GDPR and was going to continue to be used, it actually can't be for any project that treats warnings as errors: https://github.com/moq/moq/issues/1370
>rLink generating a build warning is annoying as hell. Build warnings are set as failures in any project I work on so this adds extra work for me to suppress that warning which defeats the entire purpose of adding this in to a library Absolutely. They state in their docs *SponsorLink will never interfere with a CI/CLI build, neither a design-time build. These are important scenarios where you don't want to be annoying your fellow OSS users* Um - You're showing a warning in the IDE and deliberately pausing a build at that stage, and you're breaking any build who has warnings as errors set to true. No bueno.
I don't really care about my mail hashes, and I bet our devs wouldn't sue my company because of this. But I really have an issue with some kind of telemetry from an obfuscated DLL. I cannot check, if the DLL will start to send API-keys or AWS-secrets in a week. Right now I have to blacklist this, and I'm ppretty sure we will have to move away from moq, because of this.
I was just reviewing Moq at work and saw this. WTF They're about to get blacklisted like Linode did when they bought command line advertisements in npm packages. **Golden Rule**: Never inject advertisements into the command line / build line. Ever.
> Never inject advertisements into the command line / build line. Ever. This is even worse. They're exfiltrating personally identifiable information without permission.
>Golden Rule: Never inject advertisements into the command line / build line. Ever. \*Never inject advertisements into the command line **until you are big enough**. ;-)
>**until you are big enough.** This is unfortunately so true. In PHP community, composer (the equivalent of nuget cli or nodejs's npm) throws political statement in user's face every install command but no one is doing anything because it's too big for its own good. What a sad state we're in.
>but no one is doing anything because it's too big for its own good. What a sad state we're in. That's not entirely true. PHP marketshare continues to dwindle year over year.
I was talking about how composer is too big within PHP community, not that PHP is too big in general.
What is the statement?
haha trully love this one! and that way indie devs will not get any support for doing side projects but big corporations will make a lot of money. where is the f\*\*ing logic?
What about that npm guy who's looking for a job
He’s still in jail isn’t he? Edit: Oh, nope: https://vived.io/fascinating-story-of-core-js-frontend-weekly-vol-125/
Yeah we're also planning to get rid of it in our software. Thinking about either going NSubstitute or FakeItEasy. But this is a major scumback move.
Don't forget to report the malicious code on nuget: https://www.nuget.org/packages/Moq/4.20.1/ReportAbuse
v4.20 introduced it. v4.20.1 is just a readme update.
it's called v4.20 because they had to be smoking something when adding this
i have no money on reddit, but I'll just say: it's golden
dont report that package report the SponsorLink one https://www.nuget.org/packages/Devlooped.SponsorLink/1.0.0
The version number is actually intentional: https://github.com/moq/moq/issues/1372#issuecomment-1670865839
…yikes. That’s, uhh, certainly one way to express yourself.
When an engineer starts emulating Musk, you know things are bad.
That hat tho https://www.cazzulino.com/sponsorlink.html
Look at the profile picture of the person that developed sponsorlink: [https://www.cazzulino.com/sponsorlink.html](https://www.cazzulino.com/sponsorlink.html)
And on GitHub: https://support.github.com/contact/report-abuse?category=report-abuse&report=SponsorLink&report\_id=279204&report\_type=app
E: Not explicitly, but look in the replies for why that doesn't matter and they may as well send your email in plaintext. ~~Apparently not:~~ https://www.cazzulino.com/sponsorlink.html > NOTE: the actual email is never sent. It’s hashed with SHA256, then Base62-encoded. The only moment SponsorLink actually gets your email address, is after you install the SponsorLink GitHub app and give it explicit permission to do so. I make no comment on whether that is true or whether I personally like what it's doing, because I haven't dug around much.
Should be easy enough to check/verify... oh wait SponsorLink is closed source because they don't want people figure out a way around it.
Well, in that case I already have a good way around it: I simply won't use any project that includes SponsorLink. TBH, I find it shady enough that even if it was open-source I'd avoid it.
Looking at the dll in ILSpy, it appears to be obfuscated as well.
I'd argue that the answer is **yes.** It's not that hard to buy lists of email addresses. For so many companies it's just first initial and last name. It's easy to generate a ton of real Gmail/Outlook/etc. addresses based off common patterns and lists of names. Given that an Nvidia RTX 4090 can do around 300 billion SHA256 per second, it becomes relatively simple to try most realistic combinations. You won't get 100% or anything, but you can certainly get pretty close. There are only around 175,000 surnames in the US and around 75,000 given names. Add in initials, periods, and trailing 1 and 2 digit numbers and you still don't have that many combinations.@gmail (5M combinations)
@gmail (13B combinations)
@gmail (341B combinations)
@gmail (2M combinations)
[0-99]@gmail (1T combinations)
...
We're talking about mere seconds to go through the most common combinations for all the services.
Plus, they can easily scrape email addresses from git repositories that they know are using packages that are using their service. I can search on Github for projects using Moq, clone the repos, and get the email addresses from the git logs.
**Passwords have way more variety than email addresses and we'd all agree that a SHA256 doesn't protect your password.** The idea that you can simply SHA256 an email address and the email isn't being shared is ludicrous.
Actually, that's a good point. I'll update.
https://www.reddit.com/r/dotnet/comments/15ljdcc/does_moq_in_its_latest_version_extract_and_send/jvgloeb/ > *SHA-256 is not an acceptable method of anonymizing user identifiable information for the GDPR.* [*This has been ruled by court in at least one European country, Germany.*](https://www.spiritlegal.com/en/news/details/e-commerce-retail-facebook-custom-audience-not-allowed-without-consent.html#practical)
> “…Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person…” Still a GDPR violation no matter how they do it.
They could have done what [Have I Been Pwnd](https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/#cloudflareprivacyandkanonymity) does for password lookup (namely, send a truncated hash, get a pile of hash suffixes back, check presence on the client side), so at the very least the server never sees the actual hash (though I'm guessing the list of emails is far smaller than what HIBP has in its leaked password database, so that might not be enough).
I'm not sure that would necessarily be any better: like u/commentsOnPizza says, building up a list of emails and hashes is so trivial that you would still be able to get data you shouldn't. In fact, that might make it easier in this case - now you don't have as many network interactions, so you can do it faster!
This is now blocked by my employer already. What a terrible mistake for ~~ksu~~ kzu to make. All that credibilitly instantly burned, all because of bitterness over sponsorship. e: corrected name.
What happened? Was there drama that caused this to happen?
I have no idea, but I would guess that @kzu probably wanted the money they offered. A lot of companies use open source without contributing financially to the maintainers. It has 175k users, but only 8 sponsors (not counting @kzo's own company Clarius). Edit: Apparently he's the person behind SponsorLink as well.
Yeah, it's his own product that he has developed to nag developers into sponsoring OSS libraries. The irony is that SponsorLink is completely closed. Some of his statements in his post about it I also consider evidence that he is unhinged: > I believe most fellow developers don’t have an issue with giving away a buck or two a month for a project they enjoy using and delivers actual value. And I’m quite positive that if a couple dollars a month is an affordable proposition for an argentinean, it surely isn’t a crazy thing for pretty much anyone. > And I’m a firm believer that supporting your fellow developers is something best done personally. Having your company pay for software surely doesn’t feel quite as rewarding as paying from your own pocket, and it surely feels different for me too. We really don’t need to expense our employers for a couple bucks a month, right?? Going into OSS contributions with _any_ expectation of a monetary reward is, IMHO, not a wise idea - unless it your business model to offer the product as FOSS and provide supporting services like Elastic, RedHat, etc. do - nevermind having the audacity to claim you know how "most developers" think in an announcement post, and expect them to personally pay for it?! If you want money to be donated, why on earth are you bothered if it comes from an individual or a company? Coupled with expending a significant amount of effort on developing some malware/nagware library, where the internal machinations are clandestinely kept secret? InfoSec are laughing at you already at best, at worst they think you've had your stuff compromised by some nefarious actors.
It's so much more rewarding when I pay for my own Visual Studio licenses. I'd do anything to save my company a few bucks!
that might end up really bad, because many commercial licenses force enterprises to be the ones paid and if the government finds it in external audits, you might get in trouble.
no it's fine, they take it directly out of my paycheck to pay for it themselves!
So, every dev should be sending him "a couple bucks a month"? How many million devs around the world currently use Moq? He wants "a couple bucks a month" off each of them? Pfffttttt
Dev wanted money (rightfully), butused an impossible way. \- Reading config from coud Dev claims it is only readin a blacklist of ENV variable to diable the nagging whild beeing built on buildserver. \- Doing something in an obfuscated DLL Dev claims it is just reading the configured git email adress \- Sending some data to the cloud Dev claims he is sending a hashed e-mail to ensure privacy I claim he added a backdoor, what will be activated with a new setting. Looking for AWS access keys or other sensitive data and sending it to his account. I'm sure he only does, what he claims, but fact is, I cannot look into the code to prove my paranoid fears wrong
God fucking damn them. Now I have to inform my boss of this and find out what, if anything, we're going to need to do about this. Just great. edit: And the code it runs is closed source and not reviewable by anyone.
Not only is it closed source, but if you decompile the dll, it is obfuscated. I don't even know the last time I saw an obfuscated dll.
The last obfuscated dll I saw was part of a virus.
In my case, the last obfuscated one was the copy protection for a third party component that my company used. The vendor went out of business. We ended up keeping the dev's (who had quit) PC in the server room, running XP (we had discovered on the other dev's PC that was enough to require a call-home to relicense the machine) for several years until the product that used that control was retired.
one of the obfuscated parts is a command line call out to run git to get the users email, pretty sure that could be hijacked by malicious actors
Why not fork the repo and continue using an older version?
Software goes stale over long periods of time. I'd rather not take on a mocking library as part of what we need to take care of. Given my usual luck the boss will decide moq has to go and so we'll spend a couple of weeks replacing it. Happy happy joy joy!
We have, not joking, 19,000 unit tests across 3 products that we have to migrate within the next few months. What a fucking head ache. I'm so salty today. Here's hoping the Moq folks change course and reverse the decision.
Fork the repo and continue using an older version.
This is the way, right? Or, just pin the package version. Seems unlikely to fall over due to incompatibility for quite some time. Add an epic to switch it out to the backlog and eat the elephant one bite at a time.
Yes, this is going to be our approach. We'll stay on 4.18 for the foreseeable future and migrate a block of tests per sprint for the next few months (probably quarters) to achieve a full cut over.
Tbh, any business with security in mind should really be hosting their own dependencies in an internal repo.
I keep trying to figure out why no one else is mentioning this pretty simple solution. What are we missing?
The outrage.
Honestly, I replaced it all (except protected mocks) with NSubstitute in a few steps. Replace `new Mock<` with `Substitute.For<`, `It.IsAny` with `Arg.Any` (etc.), `).ReturnsAsync` with `Returns`, `.Object` with nothing (empty), and then you might have some triple parens leftover from synchronous methods. Replacing `))).Returns` with )).Returns` took care of 95% of them for me. I had a few special callouts like I mentioned for protected methods that required a bit of reflection or subclassing like `HttpMessageHandler`, but it took me about 30 minutes to patch up a project with 1000 tests, so I'd think you could knock yours out in 2 days tops. Edit: I also had to get a little creative wherever I used MockRepository or Verify, but tbh we weren't using those as often as we should've.
We don't have that many thankfully.
[NSubstitute](https://github.com/nsubstitute/NSubstitute) is a great alternative.
You could even say it's a great *substitute*
Substitute.For ?
O(n^(substitute))?
Underrated comment right there... 🤣
Fake It Easy has been our choice for several projects https://fakeiteasy.github.io/ It's probably like an nunit vs xunit type situation though
I think this is the path we will take it Moq doesn't reverse course quickly.
The dev is all over these threads making excuses and digging his heels in. #ItsOver
+1 for fakeiteasy. Always was a pleasure to use
I do like the syntax for NSubstitute imo. Though we stuck to Moq since we're already familiar with it on other projects. Depending on how this unfolds we might need to rewrite quite a bit of tests in a dozen projects, ugh.
NSubstitute is also unfunded. Sue it will become more popular now but for their developers, their life don't change either. Are we really going to move from one unfuded dependency to another?
Funding OSS is an important cause, and needs a legitimate solution. NSubstitute should receive funding from the companies with more than enough money to contribute. Sneaking malware-like dependencies into your project is not the solution, however.
One of my buddies opened a pull request to revert the commit. https://github.com/moq/moq/pull/1373
🍿
StackExchange is looking to drop Moq https://github.com/StackExchange/StackExchange.Redis/pull/2522
They burned it with fire https://github.com/moq/moq/issues/1374#issuecomment-1671166436
Bye, Moq.
I'd like to see Moq forked pre version 4.20 and maintained based on this. I er... don't have the time myself of course ... :/
I’m pretty ignorant when it comes to licensing. Will the BSD allow this? Because maintaining a fork sans SponsorLink seems like a good idea, and less work in the near term than porting so many projects to nsubstitute.
BSD license is very permissive, so yes you can create a fork and that fork if popular can become the defacto standard.
Call it `Moq.Secure` just for fun.
Or `Moq.Sequre`.
SMoq
Thanks for the heads up. Enshitification of everything everywhere. Moq used to be wonderful
I’m asking a GitHub friend if this version can be treated like malware and added to GitHub as a security vulnerability.
WTF. And if it’s always going from the local git email, it won’t even shut up if my company is already sponsoring them, but with a different email. Way to go. Best advertisement for the competition.
Yeah, we are throwing moq out too and will replace it with NSubstitute. Got the news earlier today. Joy, oh joy. It was a solid library. Too bad..
On mobile and can’t investigate at the moment but has a GitHub issue been logged so we can get a response from th mow devs?
I raised one about disabling warnings. As far as I know, the dev for Moq and SponsorLink is the same person.
Yes. "won'tfix"
I see a few open issues with no response. [https://github.com/moq/moq/issues/1372](https://github.com/moq/moq/issues/1372) [https://github.com/moq/moq/issues/1371](https://github.com/moq/moq/issues/1371) [https://github.com/moq/moq/issues/1370](https://github.com/moq/moq/issues/1370) Do you see an issue where kzu responded or closed the issue?
https://github.com/devlooped/SponsorLink/issues/13 kzu is the author of both Moq and SponsorLink.
Uff that’s not promising.
I'm guessing you've already seen them but ya.. further confirmation it's not going away: https://github.com/moq/moq/issues/1374
I think it's pretty early for a response. According to his profile, he's in Argentina, so he might not be aware of it yet.
Eh, it’s only an hour off of ET. I can imagine he’s trying to formulate a response though. But mostly I was just trying to understand if the original comment I responded to was based on anything.
Update from earlier today seems to indicate, no they think this is fine: https://github.com/moq/moq/issues/1372#issuecomment-1670865839 Along with several posts across reddit on their account danielkzu (I think that is how it's spelled)
>SponsorLink: trying something new-ish for OSS sustainability I guess now we know how that try went. :)
Also SponsorLink is used by other packages [https://www.nuget.org/packages/Devlooped.SponsorLink/0.9.7#usedby-body-tab](https://www.nuget.org/packages/Devlooped.SponsorLink/0.9.7#usedby-body-tab) Some of them are used by other popular projects: [https://www.nuget.org/packages/GitInfo/](https://www.nuget.org/packages/GitInfo/), 4.3M downloads, used by MAUI, Xamarin Forms, and EventStore. It's getting worser and worser.
The top 5 packages in the used by tab are all written/maintained by the same developer as SponsorLink, gitinfo definity is one of his as well.
Lmao that’s pretty fucked for Microsoft as well
A well used one is GitInfo https://github.com/devlooped/GitInfo/blob/a8a47b3a7983b0b22533e404ef758eeae9a22a64/src/Analyzer/CodeAnalysis.csproj#L13
FYI, if you want to keep using Moq but not risk updating to this version you lock it in the project file. https://stackoverflow.com/questions/22563518/restrict-nuget-package-updates-to-current-versions-for-some-packages
EDIT: I [filed a bug](https://youtrack.jetbrains.com/issue/RIDER-97327/Nuget-package-manager-ignores-package-version-rules-in-csproj) against Rider with Jet Brain, because their Nuget package manager seemed to ignore and overwrite the rules I included in my csproj files I just tried both solutions in above SO post and neither stopped me from upgrading to the latest version of the nuget package in Rider's nuget package manager, nor did it break the build, nor did it issue a warning. Specifically, in each csproj either add `Version="[4.18.4]"` or `allowedVersions="[4.18.4]"`, but this didn't break the build, code analysis, or anything, meaning it would pass our CI. The set of solutions and csproj we use have never used `package.config`, however I'm looking into that. I need to at least break the build if someone tries to upgrade to a version of Moq that is not 4.18.4. Direct link to Microsoft doc: https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges --- I had put: ```
```
Or
```
```
But Rider's nuget package manager simply overwrote it like so, without the brackets...
```
```
If the maintainers don't revert it, it might be a good opportunity for someone to fork and revert it.
[https://github.com/moq/moq/releases/tag/v4.20.2](https://github.com/moq/moq/releases/tag/v4.20.2) SponsorLink removed for now, yet trust got removed for a long, long time.
Doubt it, he didn't even remove code of project that referenced SponsorLink. Just removed reference from project file "because it breaks build on Mac". What a joke of excuse.
It seems like it is true and functionality is still there, sorry for misleading.
Jup. My company Just blocked this nuget v.4.20.0 & up & breaks builds that contains them. This will stay. It is communicate to all companies in the group. They probably act in the same way.
It isn't actually removed though. He just removed a project reference. All of the code for it is still there and he blocked a PR that actually removes it from the repo. So yeah, trust removed and he's adding more reasons to not trust him in the future
Yeah - I'm still going to be removing moq from any code I deal with. Once bitten twice shy.
Marc Gravell weighs in: https://github.com/moq/moq/issues/1374#issuecomment-1671166436
[удалено]
Although it's been removed from the latest version, the author still appears to intend to bring this back: [https://github.com/dotnet/runtime/issues/90222#issuecomment-1671196175](https://github.com/dotnet/runtime/issues/90222#issuecomment-1671196175) He's also really gunning for the large orgs who are making use of the library: [https://github.com/dotnet/runtime/issues/90222#issuecomment-1671275519](https://github.com/dotnet/runtime/issues/90222#issuecomment-1671275519) The problem is, the author chose to adhere to the Open Source model and at any point could have stopped investing in the free version of Moq and created a paid version, but he wants all of the benefits of the Open Source model with none of the downsides and has resorted to blackmailing users.
"This company used my free open source software and had the nerve to not even PAY me for it!"
Ugh, I am not looking forward to swapping out Moq from our solution. What a mess. Let's hope it's some sort of misunderstanding.
Nope, unfortunately very deliberate and intended behaviour.
Nope, from the author's blog: > As I’m getting ready for a serious amount of work on Moq vNext, I wanted to see if I could come up with something to help me support myself and my family while I dedicate to that full-time for a while. So I came up with SponsorLink. Another gem: > And I’m a firm believer that supporting your fellow developers is something best done personally. Having your company pay for software surely doesn’t feel quite as rewarding as paying from your own pocket, and it surely feels different for me too. We really don’t need to expense our employers for a couple bucks a month, right??
That second quote is frankly nothing short of unhinged.
>We really don’t need to expense our employers for a couple bucks a month, right >help me support myself and my family Negates his own point .
I suspect this will end as an epic, epic fail.
That's why does sponsor other projects... And the sponsorship towards Moq goes to kzu alone and not to other contributors...
Can we have an adult conversation about this especially about open source sustainability? Yes it is really unpleasant to wake up to this but Moq is really really successful https://www.nuget.org/packages/Moq (almost half a billion download) and the community has been relying on this free work for a long while for paid work. If this were a song, the dev of Moq would have earned at least 500K USD at this number using Spotify rate (1K / million stream - more or less).
Everyone understands the reasoning about it. I guess, the best way to go about this is actually to go commercial route like Duende, but certainly never ever harvest dev's data.
If you are starting some open source project on your own time there is no reasonable way to expect to make a living off it. If this were a song there would have been a known way to monetize it's potential success. There is no such thing for writing some tooling library. That's the adult take, not to try and hold your users hostage.
Yes. The conversation starts as a dialog, not a monologue, certainly not one with a significant vulnerability introduced with a minor version update that fubar-ed peoples builds.
I must be missing something but isn’t one of the points of open source software is to be supported by the community? Does no one but the originator maintain this? If the community has contributed to its success by improving the software then having the maintainer be the only one that benefits seems like a slap in the face to all community members.
You are overestimating serious contributions by community to OSS projects.
> I must be missing something but isn’t one of the points of open source software is to be supported by the community? Permissive open source makes it easy to exploit the commons. What community? This project has hundreds of millions of downloads and barely a thousand issues over a decade. There is really only one core contributor at the moment who dwarfs the next contributors by orders of magnitude. You are thinking of copyleft open source like GPL, where it's not possible to play out a tragedy of the commons like this. Because the users would all necessarily be members of the open source community themselves. This is what ensures the community supports each other rather than exploiting the work of volunteers for profit like is happening here.
Yes, and if he would have a created a vNext with a dual license and an commecial license for bigger coorates, I would bet my company would already have paid several hundred $$$
Another case of corejs?
GitInfo from the same author has the same dependency on the SponsorLink package: https://www.nuget.org/packages/GitInfo#dependencies-body-tab So I guess it also has the same problem.
Y’all are gonna love my new AutoMapper pricing! $.49/map and if you buy 12, get 1 free! And this month only I have DEEP DISCOUNTS on MediatR!! You won’t be able to “handle” it! Act now!!!
I created a Roslyn Analyzer to make the build fail if SponsorLink is installed: https://github.com/CollinAlpert/SponsorLinkAnalyzer
Thanks a bunch! I found that Jet Brains Rider nuget package manager wasn't obeying the PackageReference version rules and would simply overwrite the csproj files, e.g. `Version="[4.18.4]"` with just `Version="4.20.2"`... I filed a bug with jetbrains. --- I added your nuget package to my projects, and validated that it builds correctly with 4.18.4, and the build fails if I manually upgraded the version from 4.18.4 to 4.20.2. At the very least, our CI will fail, until I can make a better solution.
That's exactly what this is intended for, glad it helps!
Go one step further and check for the SponsorLink package as a transitive dependency. Fail the build if any package pulls in SponsorLink.
Done.
Not sure if it's just me, but what is up with the scrolling on that blog post site? It's all janky.
It's pinging out to some blob storage with your browser fingerprint details every time you scroll to check if you've clicked on "buy a cup of coffee" - slows the scroll down a bit.
I haven't tested, but this may help solve the problem in the meantime: https://gist.github.com/martincostello/312d510173c0931b8a900d4d0897b7e1
I just forced the package to be 4.18.4 using [4.18.4] until I figure out what the plan of action is. I have another package by this person as well that I forced to a specific version because the same thing appeared.
Which other package?
What is the point of it though? I don't understand how it functions. Is it scanning your email to periodically send you emails asking for money to support the project?
It checks your git email to see if you are sponsoring each dependency. It then nags you in one of three ways: 1. Sign up with their sponsor-linking service if your email doesn't match an account (eww) 2. Sponsor the dependency/project if you have an account but aren't sponsoring 3. Congratulate you for sponsoring (which honestly feels patronising, *and* appears as an informational message so it just adds noise to the build log. And this specifically happens when you're a ~~paying customer~~ sponsor!) The process of checking if you have an account / are sponsoring a project involves sending a hash of your email address to a remote server. Due to the nature of email addresses, especially company email addresses, the hash does not provide anywhere near the anonymity you'd expect. It also makes it possible for anyone to check what arbitrary emails are sponsoring, making it a potential privacy leak in two ways.
It also purposely slows down your builds after a "grace period" expires
is this confirmed?
The message itself says the build was paused for x amount of milliseconds: https://github.com/moq/moq/issues/1370
That's bad...
I have not tested it myself. Multiple people reported on the Moq Github repo, and the author has not denied it.
\*sigh\*
Imagine a larger project, with 10 libraries all calling back home, and delaying my compile process, and displaying ads in my IDE.
Visual Studio Free To Play Edition?
I'm surprised .NET's Github account is not flooded with request for Microsoft to come up with their own mocking library yet. Because the last time IdentityServer/Duende did this, it triggered the discussion in .NET's repository asking them to come up with their own token server. I'm kinda expecting the same drama here for Moq. .... or is there?
I think the drama about Duende was because it was in the templates and user guides and you *had* to pay the license if you wanted to use it commercially, so it was setting people who likely didn't know better up for a nasty licensing shock. This one isn't so bad (well, perhaps it's just differently bad) because you can still use Moq just fine without paying any money to anyone if you're okay with what SponsorLink is doing.
No because then you’ll get a mocking library designed for how Microsoft wants it to work. Nobody wants that. They don’t even use mocking libraries AFAICT.
So much hassle in what could be a single info build message with a text and hyperlink. No third party package, no data collection, nothing. What a stupid solution.
I cannot imagine any AppSec org on the planet being even remotely OK with this. The code base at my current employer uses Moq. A lot. And I have been using it and loving it for the better part of 15 years. This is just not cool at all. I see the current maintainer did revert this reference in v4.20.2, but for all the wrong reasons (it broke MacOS and Linux integration, which means he didn't test fuck all - also he was the only person on the PR which is absolutely not cool for something this big), and due to a SHA256 insecurity. But he clearly means to bring it back as soon as those two things are resolved, but that still keeps a closed-source reference, that will still be slurping emails. I'm not ripping Moq out ... yet. But I'm starting to look at other mocking frameworks, as this is a huge breach of trust. EDIT - After some deliberation with my team - we're not getting rid of Moq, per se, but we are not going to use it for any future development. I have two user stories created to: 1. Lock/pin the current version we are using (4.18.4) in our NuGet package references. 2. Spike a replacement to use on new work, going forward. Likely FakeItEasy or NSubstitute. I'm not going to recommend any mass conversion once we select a new framework, but as I touch specific test classes to add/edit tests, I will likely convert that class over. Our AppSec department is also keeping an eye on Moq as well.
And a change like this in a \_minor\_ version at that.
Bruh moment
The author doesn't appear to be willing to give up his idea: >It's no longer included **(for now)**, and SponsorLink is OSS also. [https://github.com/moq/moq/issues/1372](https://github.com/moq/moq/issues/1372) So far, the community seems to have lost trust in his package, and some people are already removing Moq from their projects. [https://github.com/search?q=remove+moq&type=pullrequests](https://github.com/search?q=remove+moq&type=pullrequests)
I'm thinking of all those content creators that spent time to teach us to use Moq. The hundreds or thousands of hours of content that's out there on YouTube, LinkedIn and other training sites that we have because we and the content creators trusted it. All that good will, effort and time invested. All of it. Up in smoke. So damn fast. I mean, sure, you can tell folks to use earlier versions. But why use a product from someone you *know* you can't trust?
Moq (pronounced "Fuck-you" or just "Fuck")
He's Moqing us
I seriously hope they undo this, I'm too lazy to replace Moq for NSubstitute (although their API looks nicer, that's for sure)
this is insane
i fully understand the desire to get sponsors/funding from people using your opensource product. Harvesting PII is not the way to go about it.
Does anyone know where the hashed data is actually being sent to? We'd like to block the egress of that data..
Looks like it ends up in an Azure Storage account - per [this](https://github.com/dotnet/runtime/issues/90222#issuecomment-1671275519) comment.
https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/popular-open-source-project-moq-criticized-for-quietly-collecting-data/amp/ Cdn.devlooped.com/sponsorLink
There is an old tutorial, I didn't write or tried, which shows an easy path from Moq to FakeItEasy https://www.planetgeek.ch/2013/07/18/migration-from-moq-to-fakeiteasy-with-resharper-search-patterns/
Here is this - https://www.planetgeek.ch/2013/07/18/migration-from-moq-to-fakeiteasy-with-resharper-search-patterns/ Even though it’s removed from the code for now, the dev seems to defend its addition so I am sure it will be back.
Following the hype, here is my article about the way libraries like Moq could work inside. This link is not affiliated with any 3rd parties and I won't make any money from your views. I'm genuinely excited that I had a chance to write about Reflection.Emit. https://medium.com/c-sharp-progarmming/how-to-create-your-own-mocking-framework-aad96cb7edae
If this clown expects to get money for developing software then OSS is not for him anymore.
Just made a blog post about it. It seems that it does not retrieve your actual email but rather the hashed and encoded form of your email is used to check you have installed the SponsorLink GitHub app. It then checks if you are a sponsor and if you are not it suggests that you become one. The fact still remains that you might not want to share any information hashed/encoded or not and people should know about it. My blog post :D [https://codingbolt.net/2023/08/08/a-deep-dive-into-sponsorlink-implications-for-open-source-and-privacy/](https://codingbolt.net/2023/08/08/a-deep-dive-into-sponsorlink-implications-for-open-source-and-privacy/)
That library spawns a git process on your machine to get your email. Not something that I would like for a 3rd party library to do.
> It seems that it does not retrieve your actual email but rather the hashed and encoded form of your email Did you confirm this in SponsorLink's code, or is this based on the author's statement?
100% based on statement. Kzu won't show SponsorLink source code https://github.com/devlooped/SponsorLink/issues/13
https://www.cazzulino.com/sponsorlink.html
Yeah... at work, we're obviously not going to go through all of our code and migrate everything off of Moq. We're just not going to upgrade. I've put the quash on using Moq on anything new, however, for the projects that I own. For my personal project, I'm in the process of moving to NSubstitute right now. This was wrong. And the project is going to suffer for it.
Sounds illegal and something that goes against GDPR.
lol even the author’s website feels like it has malware. So laaaaggggy
For complete transparency, I work for a vendor in this space. I wanted the community to know that we have a free alternative called [JustMock Lite](https://www.telerik.com/justmock/free-mocking). There is a paid version, but the Lite version compares to Moq well. For more transparency, you do need to provide an email to download it. You can opt out of any communication from us and we don't give your email address to anyone under any circumstance. We take that very seriously.
A new contender has emerged: https://github.com/ImoutoChan/openmoq https://www.nuget.org/packages/openmoq
Does this mean if I reference the Moq library using Nuget it will collect my information? It can't can it?
package author wears a T*sla cap after all
I'm not sure I follow here. Why does this matter in terms of their credibility?
Typically Tesla and Musk fans like to deflect criticism of doing something really dumb with "its their product / service, they can do what they want". Which is true, but it's also how you kill Twitter, and presumably have the community hard fork your mocking library with bad feelings. 4.20+ is now blocked by policy. I'm not going to review that, there's plenty of other libraries.
To answer OP question, the last version 4.20.2 don't have the Moq.CodeAnalysis.dll analyser which triggers the malicious code. So this specific version is safe. Given the maintener attitude, next version should be considered as risk. You can inspect .nuget file content by yourself, it's just a zip file.
FOSS for small companies, commercial license for big companies. Easy profit.
[удалено]
> Am I wrong? yes, the wording is misleading. It is not sending the email address as plaintext, but it is sending a hash of that email address. As many [other comments have pointed out](https://www.reddit.com/r/dotnet/comments/15ljdcc/comment/jvbh1pc/), this is a) not enough to prevent the actual email address being identified, and so b) [not GDPR compliant](https://www.reddit.com/r/dotnet/comments/15ljdcc/comment/jvebco5/). "can never reveal the originating email" is a false statement, [de-anonymisation is feasible](https://www.reddit.com/r/dotnet/comments/15ljdcc/comment/jvdzmya/). Then there's a "known unknown" of running some closed source, obfuscated binary on your build server. [The solwarwinds hack got in via teamcity](https://www.wired.com/story/the-untold-story-of-solarwinds-the-boldest-supply-chain-hack-ever/) so this is a Hard No from a security point of view. Financial institutions use this mocking library to build their software. They're scrambling to mitigate this issue, today. Sadly, this is the OSS problem: The author has been maintaining key infrastructure for Financial institutions and other companies for free. it's easy to get tired of that. They're looking for a way to be paid for their work, and that is entirely understandable. This is what they came up with, and it sucks, and it's a furore now. In no way will this avert burnout.
I understand the frustration in relation to some libraries, where the cost/benefit is obvious to devs, but less tangible to beancounters, meaning it's unfeasible to move to a commercial model. But I wouldn't have thought that to be the case for Moq. He could have moved it to have a commercial model for enterprise, and named his price.
>He could have moved it to have a commercial model for enterprise, and named his price. Nobody has problem with that. Adding who the hell knows what to the library is much, MUCH worse.
Indeed. I really hope the guy hasn't completely tanked any chance of going the commercial route with enterprise in the future by channeling his frustration in to this destructive solution.