Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Devlooped.SponsorLink analyzer should not contain obfuscated code #9

Closed
sharwell opened this issue Apr 5, 2023 · 15 comments
Closed
Labels
question Further information is requested

Comments

@sharwell
Copy link

sharwell commented Apr 5, 2023

See the title. Users need to be able to understand the code being injected into a build. This is important for transparency and trust.

@sharwell sharwell added the bug Something isn't working label Apr 5, 2023
@kzu kzu added the wontfix This will not be worked on label Apr 10, 2023
@kzu
Copy link
Member

kzu commented Apr 10, 2023

That would make it trivial to bypass the SponsorLink check. So, this is by design at this point unless there's serious concerns raised by a large portion of users.

@kzu kzu closed this as completed Apr 10, 2023
@kzu kzu added question Further information is requested and removed bug Something isn't working labels Apr 11, 2023
@NickMOrlando
Copy link

NickMOrlando commented Aug 8, 2023

That would make it trivial to bypass the SponsorLink check. So, this is by design at this point unless there's serious concerns raised by a large portion of users.

What constitutes a large portion of users?

The introduction of this package into Moq has spawned a significant number of concerns over that package's viability in any F/OSS or Corporate environment.

@CryoMyst
Copy link

CryoMyst commented Aug 9, 2023

Developers are not going to accept telemetry without transparency.

@Atulin
Copy link

Atulin commented Aug 9, 2023

"Trust me bro" isn't much of an assurance when it comes to running arbitrary code on the user's machine.

@cygnim
Copy link

cygnim commented Aug 9, 2023

@kzu I'd say serious concerns have now been raised. The vast majority of users don't even know this change has been made and would have a problem. Trust with moq is now broken as has GDPR. This is underhanded to say the least. Be one of the good guys.

@Ibmurai
Copy link

Ibmurai commented Aug 9, 2023

That would make it trivial to bypass the SponsorLink check. So, this is by design at this point unless there's serious concerns raised by a large portion of users.

Why should it not be trivial to bypass?

@kzu
Copy link
Member

kzu commented Aug 9, 2023

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

Yes, I'd consider serious concerns have been raised. I'm evaluating bringing the analyzer code over to this repo. I'd like to bring it with its commit history so that it's clear how it came about too. Need to brush up my git-fu :)

@CookiePLMonster
Copy link

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

This exact mindset is likely going to incentivize people further to challenge this assumption and work harder on cracking down on whatever obfuscation you've applied. Clearly you've not researched how determined reverse engineers can be against such challenges.

@cygnim
Copy link

cygnim commented Aug 9, 2023

I think the point is, this funding model is inherently dishonest and should be abandoned immediately.

@hilari0n
Copy link

hilari0n commented Aug 9, 2023

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

So you are basically using an extortion tactic. I.e. "I will not stop snooping on you and annoying you, until you start paying and then we'll call you my sponsor."
The idea of sponsoring is that anyone not able or not willing to sponsor can simply and easily say "no" and not be bothered afterwards.

Yes, I'd consider serious concerns have been raised. I'm evaluating bringing the analyzer code over to this repo. I'd like to bring it with its commit history so that it's clear how it came about too. Need to brush up my git-fu :)

Unfortunately it looks like too little, too late. 😞

An acceptable solution could be one where the package displays an information message in IDE, asking the user to be a sponsor (without extracting and divulging any data), explaining how you can become one and how you can suppress this message or (better) showing you a link to a page where you can read how to become a sponsor and how to suppress the message.
This way you would not be invasive and even if you would not gain many sponsors, you could at least bring more people to the discussion. (I've only just found out that you've been discussing it with some unnamed developers and I have seen no traces of such discussion.)
The next step would be to use a new message (with a new, but still simple way for suppression) informing, that from version X.Y.Z you will be developing 2 separate variants of a package, one free, offering only the existing functionality and maybe fixes and another one, which will be commercial.
A different approach could be to talk to Microsoft, on the NuGet.org offering a way to advertise option to support package creators. E.g. similarly to how npm does show messages about package authors looking for funding.

All in all, there's probably a multitude of ways to do this, without harvesting personal data without consent and without annoying people, as both of those tend to rather drive people away, instead of bringing new sponsors in.

@ScarletKuro
Copy link

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

Any skilled .NET engineer possesses the capability to bypass through this obfuscated code. I am convinced that any motivated individual could do so, as even dead de4dot can still dismantle a portion of the obfuscation present in the DLL, also replacing some IL code is not a problem nowadays as well. However, I'm skeptical that any reputable software engineer would do it, but if they do, I doubt they would sponsor whoever uses Devlooped.SponsorLink anyway.

This is not the main point tho. By obfuscating and keeping the source code closed, you create a barrier for audits, especially in highly secure environments. You are attempting to conceal the inner workings of your program, but there is no assurance that a future update of Devlooped.SponsorLink won't introduce unexpected elements, such as a Bitcoin miner(just an example). Sadly, I've come across numerous of paid software developed by individuals that contain hidden backdoors to take revenge if something happens.

I strongly believe that projects like these libraries should prioritize transparency. The primary goal of this library should revolve around capturing developers' attention, highlighting its donation avenues, and encouraging sponsorship if feasible. This is why I'm puzzled by the idea of obfuscation – after all, those uninterested in sponsoring won't be swayed regardless.

@wdolek
Copy link

wdolek commented Aug 10, 2023

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

It's easier to send few bucks than trying to figure out how to bypass message somewhere (even trivial one). Even your obfuscated closed source solution can be bypassed after all 🤷 - this cannot justify malware-ish behaviour of this library.

@Kryptos-FR
Copy link

Because if it's trivial to bypass, nobody would donate and we'd be back to the same situation that sparked the desire to get funding?

It is already trivially by-passable but just putting fake email/user in .gitconfig (or better a know contributor's address) and using an alias to inject the real one into each git commit command. So you have no gain anything by this, and just lost the community's trust instead.

And about the obfuscation part: on one hand, people who don't want to pay, would still not want to pay and find a way to bypass. On the other hand, people ready to pay a sponsorship would like to be able to trust the package, which in this case they can't because of the leakage of PII.

@NiKiZe
Copy link

NiKiZe commented Aug 10, 2023

Any obfuscated analyser should be treated as virus/spyware. Will be blocking and reporting.

@kzu
Copy link
Member

kzu commented Aug 18, 2023

Analyzer and backend is all OSS in this repo now too. Locking this thread as a consequence.

@devlooped devlooped locked as resolved and limited conversation to collaborators Aug 18, 2023
@kzu kzu removed the wontfix This will not be worked on label Aug 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests