Moq grast in neusten Versionen Git Emails ab

Bin nicht sicher ob es hier passt, falls nicht bitte verschieben.
Die viel verwendete Lib moq hat in der neusten Version ab 4.20 SponsorLink eingebaut.
Diese scheint mit Obfuskated Code via git die Benutzer Emails abzufragen, zu hashen und zu verschicken.
Ist alles sehr dubios und vom Entwickler von moq selbst initiiert.

Issue auf Github dazu:
https://github.com/moq/moq/issues/1372

Wer also moq verwendet, sollte das Thema im Auge behalten.
Ggf. sollte man auch auf Alternativen ausweichen.
Das Thema schlägt bereits hohe Wellen und m.M. nach auch zu recht.

Nick Chapsas dazu:
https://www.youtube.com/watch?v=A06nNjBKV7I

T-Virus

Das Thema ist von vielen Seiten aus (Projekte, Kunde...) auch bei mir gelandet; man findet meinen Namen auch in den Moq Issues mit Kommentaren dazu.

Kurze Zusammenfassung:

• Moq verwendet seit 4.20 das externe Paket SponsorLink
• SponsorLink ist vom gleichen Entwickler unter der GitHub Org devlooped veröffentlicht
• SponsorLink holt sich aus der lokalen Git Config die E-Mail Adresse und sendet sie als SHA256 an einen unbekannten Server. Dazu wird ein externer Prozess gestartet.
• SponsorLink führt dies während der Build Time aus und schreibt in das Log, wenn die E-Mail nicht als GitHub Sponsor hinterlegt ist

Nach eindringlichem Feedback der gesamten .NET Community, Kunden und Co hat sich der Entwickler "kzu" dazu bewogen, die betreffenden NuGet Versionen zu unlisten und temporär SponsorLink aus weiteren Veröffentlichungen heraus zu nehmen.

Der Code ist aber immer noch Bestandteil des Projekts und es wurde bereits im .NET Runtime Repo angekündigt, dass es wieder kommen wird.

• Das Vorgehen verletzt GDPR, da Benutzerdaten gelesen und an externe Server verschickt werden
• Das Vorgehen sorgt dafür, dass Projekte, die Moq verwenden, ebenfalls gegen GDPR verstoßen
• Es sind sehr große Projekte betroffen, egal bei welchen Unternehmen (Microsoft, Amazon, Google....). Selbst die .NET Runtime und ASP.NET verwendet (noch) Moq.
• Das Vorgehen von SponsorLink verletzt den .NET Roslyn Contract; es ist davon auszugehen, dass Microsoft hier aktiv werden wird ⇒ https://github.com/devlooped/SponsorLink/issues/10 auch wenn er Feedback dazu ignoriert
• Es gibt mehrere Beschwerden bei GitHub und NuGet, dass die Software als Spyware deklariert wird
• Es betrifft nicht nur Moq; Moq ist nur seine größte Bibliothek. Der Entwickler hat SponsorLink auch in weiteren Projekten integriert, darunter GitInfo und ThisAssembly ⇒ https://www.nuget.org/packages/Devlooped.SponsorLink/. Wir hier im Forum verwenden ThisAssembly und Moq selbst; wenn auch Versionen, die nicht betroffen sind.

Rat zu weiterem Vorgehen:

• Wenn ihr Moq verwendet, bleibt bei maximal 4.18.4
• Helft euch aus mit NuGet Version Pinning
• Wartet paar Tage ab, was passiert.
  Die Reputation des Entwicklers und von Moq ist aber de facto tot. Die Frage ist nun, ob es ein Fork mit neuem Besitzer von Moq geben wird, oder - wie aktuell sich im NuGet Issue es sich abzeichnet - ein massiver Wechsel auf NSubstitute stattfinden wird.

Seine Intention war, dass er eine stabile Finanzierung erhält, um Moq weiterentwickeln zu können - absolut legitim und ein großes Problem der Open Source Gemeinde. 
Es ist auch nicht so, dass er bisher "nichts" bekommen hat: in der Vergangenheit gab es größere finanzielle Unterstützung zB von GitHub und AWS.

Die Art und Weise war in Summe jedoch der schlechteste Weg, eines der dümmsten Dinge, die ein Maintainer überhaupt hätte tun können. Und sehr wahrscheinlich ist er damit seinem Ziel eher weiter entfernt, als näher gekommen.

Man kann das Paket auch direkt über MSBuild blockieren

    <!-- Block Projects with Privacy/Security Concerns -->
    <Target Name="CheckBlockedPackages" AfterTargets="ResolvePackageDependenciesForBuild">
        <Error Code="420" Text="Blocked package dependency detected: %(PackageDependencies.Identity)"
             Condition="'%(PackageDependencies.Identity)' == 'Devlooped.SponsorLink'" />
    </Target>

Es wurde Version 4.20.2 veröffentlicht, wenn ich das richtig sehe wurde es damit wieder entfernt

Siehe

Nach eindringlichem Feedback der gesamten .NET Community, Kunden und Co hat sich der Entwickler "kzu" dazu bewogen, die betreffenden NuGet Versionen zu unlisten und temporär SponsorLink aus weiteren Veröffentlichungen heraus zu nehmen.

Der Code ist aber immer noch Bestandteil des Projekts und es wurde bereits im .NET Runtime Repo angekündigt, dass es wieder kommen wird.

Es wurde auch nicht entfernt, sondern nur deaktiviert, weil Builds auf MacOS im Error enden.
Remove SponsorLink since it breaks MacOS restore

Mit einem zukünftigen Update kommt es also wieder. Einsicht Fehlanzeige.

So wie sich seine Aussagen lesen, wird da auch keine Entschuldigung deswegen kommen.
Ist zwar Schade aber er selbst hat sich dazu entschieden.
Jetzt muss er mit den Konsequenzen leben.
Seine Reputation und die von Moq dürften jetzt gegen 0 gehen.
Alternativen stehen in den Startlöchern.

Link:
https://github.com/dotnet/runtime/issues/90222#issuecomment-1671736796

T-Virus

Ich gehe davon aus, dass er erst durch "hartes Feedback" kapieren wird, was er da angerichtet hat - und dass sein Weg nicht funktioniert. Das wird aber noch paar Tage dauern, bis da die großen Zahnräder aktiv werden. Er hat damit im Endeffekt sein Lebenswerk innerhalb weniger Stunden zerstört und ich bezweifle, dass sein Image jemals sich davon erholen wird; geschweige denn Moq.

Hallo,

es wird wohl auch Änderungen in Roslyn und NuGet geben (müssen):

• Roslyn wird einen Analyzer nur dann ausführen, falls kein externes IO außer AdditionalFiles ausgeführt wird
• NuGet (-Server) wird beim Indizieren der Pakete auch den Code prüfen müssen und eventuell das Paket ablehnen

Das Unding von kzu wird wohl noch größere Kreise ziehen.
Schade dass der OSS-Gedanke hier so mockig behandelt wurde.

mfG Gü

Ja, das ist leider alles sehr unschön.
Bisher ist da auch nichts von Einsicht von Kzu zu sehen.

Leider zeigt es auch die Schwächen des Gesamtsystems.
Hier hat NuGet im Grunde die gleichen Probleme wie Node.js und andere Paketquellen ohne zusätzliche Maintainer die die Pakete vor der Freigabe nochmal gegenprüfen.
Wenn der Code und die Pakete durch die ganze Kette laufen können ohne diese genaustens zu prüfen, dann kann man darüber leider sehr viel Schaden anrichten.
Leider zeigt sich in diesem Fall, dass man dabei nicht mal Vertrauen in die eigentlichen Paketbetreuer bzw. den ursprünglichen Entwickler haben kann.
Was natürlich sehr schade ist, da man diesen Leuten auch sein Vertrauen bisher gerne geschenkt hat.
Ich habe mit Moq selbst bisher nur in einem Projekt gearbeitet, fand das Konzept und die Umsetzung damit aber sehr gelungen.

Ich sehe hier auch den Versuch seitens Kzu die Situation um OSS hier als Ausrede für diese Aktion vorzuschieben.
Bzw. eine schlechte Planung was den finanziellen Aspekt seiner Arbeit an geht.
Wenn man Software Entwicklung mit einer offenen Lizenz durchführt, dann kann man leider nicht erwarten das jeder Geld dafür springen lässt.
Hier muss man sich m.M.n. möglichst vorher überlegen ob man finanziell auf der Arbeit aufbauen will und dann durch entsprechende Konzepte und Ansätze einen finanzielle Unterbau aufstellen.
Hier reicht es eben nicht auf Sponsoren aller Art zu warten und hoffen.
Beispiele für solche Ansätze wären kommerzielle Erweiterungen für Moq o.ä.

Die meisten nehmen freie Software heute einfach als gegeben hin ohne an die Entwickler dahinter zu denken.
Hier bräuchte es ein Gesamtkonzept um solche Projekte allgemein besser zu fördern.
Ähnlich der Linux Foundation zur Sicherung der Entwicklung von Linux und Projekten rund um Linux.
Natürlich kann man dann auch nicht alle Entwickler damit abdecken aber es würde die Situation bei passenden Gemeinschaften etwas verbessern.

Ansonsten bleibt nur der Weg direkt zur Umstellung auf ein komerzielles Produkt bzw. Lizenz.
Dies wurde auch im github Issue bei Microsoft vorgeschlagen um eben damit Geld zu verdienen.
Wäre zwar für die Masse der Projekte schade, da Moq an sich eine gute Lib ist/war.
Aber es wäre alle mal besser gewesen als git Emails mit obfuscated Code abzuschnorcheln.

Ich bin etwas pessimistich was Mopq angeht.
Ich glaube nicht, dass nach der Aktion Moq noch eine große Zukunft hat.
Mich würde es auch nicht wundern, wenn das Projekt Heute moder Morgen dicht gemacht wird.
Nach der Aktion und die ganzen Projekten die jetzt abspringen, dürfte sich das in den nächsten Tagen und Wochen auch bei Kzu bemerkbar machen.

Nachtrag:
AWS scheint schon Konsequenzen zu ziehen und will aus den ehemaligen Sponsoren entfernt werden.
Soweit ich dies lesen konnte war AWS einer der wenigen die auch finanziell einmalig eingesprungen sind.
Sollte für Kzu eigentlich ein deutliches Signal sein.

Pull Request:
https://github.com/moq/moq/pull/1381

T-Virus

Zitat von T-Virus
Hier hat NuGet im Grunde die gleichen Probleme wie Node.js und andere Paketquellen ohne zusätzliche Maintainer die die Pakete vor der Freigabe nochmal gegenprüfen.

Das ist ein generelles Thema von Projekten, egal ob Closed Source oder Open Source.

Bzw. eine schlechte Planung was den finanziellen Aspekt seiner Arbeit an geht.

Weniger ein persönliches Problem, denke ich - sondern halt ein Branchenproblem von frei verfügbarer Software.
Ich mein mir/uns gehts mit dem Forum hier nicht anders. Wir haben das jahrelang aus privater Tasche bezahlt; zusätzlich zur Zeit. Erst seit diesem August, wenige Tage also, haben wir aktuell zumindest eine Kostendeckung.....

Und dürfen uns dann noch dumm von der Seite anmachen lassen.

Ansonsten bleibt nur der Weg direkt zur Umstellung auf ein komerzielles Produkt bzw. Lizenz.

Darauf hat kzu geantwortet, dass er keine Lust drauf hat. Er will "einfach nur Open Source entwickeln und davon leben können".

https://github.com/moq/moq/issues/1374#issuecomment-1671261511

I just want to do OSS and code all day. I don't care much for negotiating support contracts with corporations and generating invoices and the like.

Daraufhin die Antwort von Marc Gravell:

https://github.com/moq/moq/issues/1374#issuecomment-1671269880

I hear you; I'd like that dream too (in the context of "my" libraries, rather than what I do as my day job) - but I need to accept that reality doesn't work that way. I also acknowledge that going from a handful of unpaying users to a huge number of unpaying users (who all want support and help and put demands on your time): just adds stress without any benefit to you. I understand every pain point you're raising, and have experienced them first hand. I get the frustration - anger, even, at basically being treated as a free resource by companies making huge benefits from your work and paying nothing.

But what you've done here pushes you further from that dream you mention, as it burns the credit the library had accumulated.

Sein Verhalten jedoch, dass er nun mit aller Gewalt weiterhin Gesetzte und Microsoft Contracts ignorieren will, und sein SponsorLink durchboxen will, lassen mich bezweifeln, dass es ihm insgesamt nicht nur um das Funding geht. Er lehnt alle Vorschläge ab.
Ich gehe davon aus, dass Microsoft dem Thema jedoch ein Riegel vorschieben wird; entweder technisch oder juristisch.

Persönlich finde ich es auch sehr kritisch, dass zB eine UnoPlatform nun Geld an kzu gespendet hat.
Das ist quasi die Belohnung für etwas, das streng genommen einfach illegal ist. Ich hätte es besser gefunden, wenn die UnoPlatform nun NSubstitute finanziell unterstützt hätten, die ebenfalls kein Funding haben.

Kleine Wende am Nachmittag, wenn auch keine große.
Kzu hat scheinbar SponsorLink als Open Source veröffentlicht.
Ist m.M.n. zu spät und dürfte dem Dammbruch nichts mehr entgegenwirken.

https://github.com/moq/moq/issues/1384
https://github.com/devlooped/SponsorLink

@Abt
Ja, da bin ich bei dir.
Ich finde es auch fraglich, dass man hier noch mit Sponsoring die Tat belohnt.
Es wurde oft genug darauf hingewiesen, dass hier ein Bruch des GDPR vorliegt und selbst ein Ersatz wie eine Guid hier keine saubere Lösung wäre.
Ich schau da noch eine Weile drauf aber das Schiff ist im großen und ganzen abgefahren.

T-Virus

https://twitter.com/kzu/status/1689666564356714496

And now everyone can move on from the hysterics about me collecting emails to send to some third party malicious actor (well, unless you think @Azure storage is one). PRs welcomed in that repo in particular

Er hats immer noch nicht verstanden - und er wirds auch nicht verstehen.

Komisch, ich sehe folgende Meldung.

Scheinbar hat er schnell den Text geändert...

I'm sorry if I haven't been as active today as yesterday with the feedback, but it's the first time I had to unify two repos. Ended up cherry-picking every commit from the core impl. on top of the SposorLink public repo. There's surely a few stupid things here and there

T-Virus

Ich hab (mit Absicht, für den Kontext) den Parent-Tweet verlinkt.
Der zitierte Text ist der Sub-Tweet: https://twitter.com/kzu/status/1689666566474919936

@Abt
Alles klar, bin auf Twitter/X nicht mehr aktiv bzw. logge mich nicht mehr an.
Da Elon die Ansicht stark beschnitten hat, konnte ich es nicht sehen.
Aber danke für den Hinweis!

T-Virus

Gibt eine neue Version von moq, man beachte die Versionsnummer 😕
Langsam fühlt sich das ganze fast wie trollen an.

Release Notes:
https://github.com/moq/moq/releases/tag/v4.20.69

T-Virus

Hallo,

es ist jetzt einige Zeit vergangen und ich wollte einmal Nachfragen wie ihr damit umgeht.

Bei bestehenden Projekten mit Moq sind wir bei Version 4.18.4 stehen geblieben.
Jetzt haben wir ein neues Projekt und verwenden erstmalig Nsubstitute. Damit lassen sich die Testfälle genauso abdecken wie mit Moq. Aber, mir persönlich gefällt es nicht in einigen Projekten Moq zu verwenden und in anderen Nsubstitute. Und jetzt die älteren Projekte auch auf Nsubstitut zu migrieren → da gibt es wichtigeres zu tun.

Verwendet ihr weiterhin Moq auch in neueren Versionen oder seid ihr gewechselt? Wie ist euere Herangehensweise?

glandorf

Aktuelle Projekte, an denen noch aktiv gearbeitet wird, komplett auf NSubsitute umgezogen, sowohl eigene wie auch Company-/Kunden-Projekte.
Gilt auch für alle weiteren Libs des Autors - das Vertrauen ist da einfach komplett gebrochen und die Gefahr viel zu groß.

Hab sehr viel mit Copilot oder ChatGPT/Azure OpenAI an der Stelle automatisiert; ging selbst mit großen Solutions sehr fix.

Aber, mir persönlich gefällt es nicht in einigen Projekten Moq zu verwenden und in anderen Nsubstitute. Und jetzt die älteren Projekte auch auf Nsubstitut zu migrieren → da gibt es wichtigeres zu tun.

Wir haben bei jeglichen Testanpassungen die Regel, dass Moq rausgeworfen wird.
Teilweise wurde also in einem Rutsch migriert, teilweise nach und nach.

Hallo glandorf,

alte Projekte werden nicht migriert und die Moq-Version aber auch nicht erhöht. Einfach weil eben Anderes zu tun ist.

Gibt es jedoch in alten Projekten neue Tests, so wird für diese NSubstitute verwendet. D.h. es existiert Moq und NSubstitute parallel.
Nur wenn das alte Projekt sehr überschaubar ist, so flog Moq komplett raus.

Bei neuen Projekten ausschließlich NSubstitute, Moq hat sich disqualifiziert.

BTW: mir gefällt die Arbeit mit NSubstitute eigentlich besser als mit Moq, daher hab ich mich ein paar gefragt warum nicht schon früher einmal der Blick auf Alternativen zum (damaligen) de-facto Standard Moq gemacht wurde.

Aber Abts Blog zur KI-gestützen Migration werde ich mir noch näher anschauen. Danke für den Tipp!

mfG Gü

Hab direkt ein kleines Projekt, in dem ich Moq verwendet hab, ebenfalls auf Nsubstitute gewechselt.

Die anderen Projekte sind m.W.n. nicht umgezogen, weil einfach die Zeit fehlte.

Bei neuen Projekten würde ich auch nicht mehr auf Moq setzen, da der Entwickler mein Vertrauen verloren hat.

T-Virus

Hallo,

danke für eure Antworten.
Wir werden in neuen Projekten weiter auf NSubsitute setzen und in älteren Projekten neue Testfälle mit NSubsitute umsetzen. Wenn der Aufwand überschaubar ist, werden in älteren Projekten gleich bestehende Tests mit migriert.
Somit ist Moq mit der Zeit komplett ersetzt.

glandorf