3 ms·

Since v4.20, Moq is harvesting email addresses

74 points by Jenk 3y ago

Jenk 3y ago
@ksu added the proprietary, closed source, SponsorLink to Moq. SponsorLink will harvest email addresses from your git log(s)[0], injects code into your build[0], and is completely proprietary and closed-source. The request to share the source was denied, with the reason given that it would be trivial to bypass otherwise[1] I hope ksu comes to their sense soon enough at just what an unfathomably huge security risk this presents to anyone using Moq. GDPR violations are just the start. [0]: https://www.cazzulino.com/sponsorlink.html https://www.cazzulino.com/sponsorlink.html [1]: https://github.com/devlooped/SponsorLink/issues/13 https://github.com/devlooped/SponsorLink/issues/13
- Jenk 3y ago
  Correction: kzu, not ksu.
arielcostas 3y ago
Welp, guess it can't be trusted anymore, since it contains a third-party proprietary and non-auditable package that will purposefully read a file from your system and contact a third-party internet server with a personal identifier such as an email address.
- SideburnsOfDoom 3y ago
  > and contact a third-party internet server with a personal identifier such as an email address. As has been pointed out. It is not sending the email address as plaintext, but it is sending a hash of that email address. Unfortunately this is almost as bad, is not enough to prevent the actual email address being identified - de-anonymisation is feasible in a constrained search space such as "standard email address formats such as first.last@company.com". It is not GDPR compliant: > 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. https://www.privacy-regulation.eu/en/recital-26-GDPR.htm https://www.privacy-regulation.eu/en/recital-26-GDPR.htm Then there's a "known unknown" of running some closed source, obfuscated binary on your build server. The SolarwWinds supply-chain hack got in via TeamCity so this is a Hard No from a security point of view. > it can't be trusted anymore We're going to wait and see and not apply the Moq 4.20 update. In a week the picture should be clearer. But today it looks like it's going up in flames. This is sad to see, there could have been other ways to keep everyone happy. There should be a way to accommodate the Moq dev who did something remarkable as OSS, and wants to pay the rent thereby; without this drama.
kjs3 3y ago
Crap...I think our .NET devs use this. They're gonna be just thrilled they've got to find another solution.
- AlfeG 3y ago
  Just don't update to 4.20 until https://github.com/moq/moq/pull/1373 https://github.com/moq/moq/pull/1373 resolved
  - klauserc 3y ago
    Maintainer rejected the PR. They have temporarily disabled the integration in https://github.com/moq/moq/pull/1375 https://github.com/moq/moq/pull/1375 but kept the SponsorLink project reference in the source code. It seems like their intent is to re-enable the integration at a later point :( NSubstitute [0] might be an alternative. Or to fork Moq pre-4.20. [0] https://nsubstitute.github.io/ https://nsubstitute.github.io/
    - kestrel1971 3y ago
      His intent is clear and this has destroyed fundamental trust in the project. I will be spending the next few weekends removing Moq from every project in my repos and, regardless of what happens from this point forward, I will never use it again. I hope this results in a fine from the EU for violating the GDPR - this kind of sneaky action needs to be slapped down very, very hard.
minedwiz 3y ago
Yep...just saw this today and now get to rip it out of everything. Thankfully, I've been slogging to try to get my team to adopt NSubstitute. Sounds like I just got some ammo.
devodo 3y ago
If you're looking for alternatives to Moq please check out DivertR, a mocking framework I have created https://github.com/devodo/DivertR https://github.com/devodo/DivertR

74 points by Jenk 3y ago

Jenk 3y ago

@ksu added the proprietary, closed source, SponsorLink to Moq. SponsorLink will harvest email addresses from your git log(s)[0], injects code into your build[0], and is completely proprietary and closed-source. The request to share the source was denied, with the reason given that it would be trivial to bypass otherwise[1] I hope ksu comes to their sense soon enough at just what an unfathomably huge security risk this presents to anyone using Moq. GDPR violations are just the start. [0]: https://www.cazzulino.com/sponsorlink.html https://www.cazzulino.com/sponsorlink.html [1]: https://github.com/devlooped/SponsorLink/issues/13 https://github.com/devlooped/SponsorLink/issues/13

Jenk 3y ago
Correction: kzu, not ksu.

arielcostas 3y ago

Welp, guess it can't be trusted anymore, since it contains a third-party proprietary and non-auditable package that will purposefully read a file from your system and contact a third-party internet server with a personal identifier such as an email address.

SideburnsOfDoom 3y ago
> and contact a third-party internet server with a personal identifier such as an email address. As has been pointed out. It is not sending the email address as plaintext, but it is sending a hash of that email address. Unfortunately this is almost as bad, is not enough to prevent the actual email address being identified - de-anonymisation is feasible in a constrained search space such as "standard email address formats such as first.last@company.com". It is not GDPR compliant: > 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. https://www.privacy-regulation.eu/en/recital-26-GDPR.htm https://www.privacy-regulation.eu/en/recital-26-GDPR.htm Then there's a "known unknown" of running some closed source, obfuscated binary on your build server. The SolarwWinds supply-chain hack got in via TeamCity so this is a Hard No from a security point of view. > it can't be trusted anymore We're going to wait and see and not apply the Moq 4.20 update. In a week the picture should be clearer. But today it looks like it's going up in flames. This is sad to see, there could have been other ways to keep everyone happy. There should be a way to accommodate the Moq dev who did something remarkable as OSS, and wants to pay the rent thereby; without this drama.

kjs3 3y ago

Crap...I think our .NET devs use this. They're gonna be just thrilled they've got to find another solution.

AlfeG 3y ago
Just don't update to 4.20 until https://github.com/moq/moq/pull/1373 https://github.com/moq/moq/pull/1373 resolved
- klauserc 3y ago
  Maintainer rejected the PR. They have temporarily disabled the integration in https://github.com/moq/moq/pull/1375 https://github.com/moq/moq/pull/1375 but kept the SponsorLink project reference in the source code. It seems like their intent is to re-enable the integration at a later point :( NSubstitute [0] might be an alternative. Or to fork Moq pre-4.20. [0] https://nsubstitute.github.io/ https://nsubstitute.github.io/
  - kestrel1971 3y ago
    His intent is clear and this has destroyed fundamental trust in the project. I will be spending the next few weekends removing Moq from every project in my repos and, regardless of what happens from this point forward, I will never use it again. I hope this results in a fine from the EU for violating the GDPR - this kind of sneaky action needs to be slapped down very, very hard.

minedwiz 3y ago

Yep...just saw this today and now get to rip it out of everything. Thankfully, I've been slogging to try to get my team to adopt NSubstitute. Sounds like I just got some ammo.

devodo 3y ago

If you're looking for alternatives to Moq please check out DivertR, a mocking framework I have created https://github.com/devodo/DivertR https://github.com/devodo/DivertR