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

Will cause packages to be no-go in corporate #16

Closed
DanielCordell opened this issue Aug 8, 2023 · 22 comments
Closed

Will cause packages to be no-go in corporate #16

DanielCordell opened this issue Aug 8, 2023 · 22 comments
Labels
bug Something isn't working

Comments

@DanielCordell
Copy link

Just echoing the points that other users have made here. The current implementation (with closed source & obfuscated package) basically means that a lot of corporate environments with half decent security measures on what packages are allowed won't touch anything like this with a 10 foot pole. I'm sorry, but while I genuinely think this is a fantastic idea, I don't think it's viable to use any libraries that integrate this unless people have both proof of what is actually happening (full open source) and the ability to turn it off at the solution/project level. Moq is a good example where I and I'm sure many others are having to consider our options for migration away from it.

@DanielCordell DanielCordell added the bug Something isn't working label Aug 8, 2023
@DanielCordell
Copy link
Author

Not even considering the fact that many places may have treat warnings as errors, causing this to unexpectedly cause builds to start failing.

@Porkechebure
Copy link

LMAO I am quite happy with this plot twist.
This is one of the top challenger in the "Shit lbraries list" along with log4net, Entity framework, and so on (list is long, I can't remember every shitty lib I had to work with).
I'm always happy when devs self inflict these public harakiris and such crappy libs become less popular or disappear. Bugged, spaghetti code, low maintainable and poorly understandable code horror libraries should always undergo such process and get erased from the internet.

Moq was terrible even before planting a virus into it, but now it's so satisfying.
Kill this thing with fire, Hey dev, plant other 2-3 adwares in it, it will bring you money!

@kzu
Copy link
Contributor

kzu commented Aug 9, 2023

Hi @DanielCordell , thanks for sharing your concerns. No CI/CLI builds will ever fail since those checks are never performed in those scenarios.

This is an EDITOR ONLY check. Hope this helps.

@dnperfors
Copy link

I am sorry, but even in my editor my build will fail when there are warnings...

@DanielCordell
Copy link
Author

Hi @DanielCordell , thanks for sharing your concerns. No CI/CLI builds will ever fail since those checks are never performed in those scenarios.

This is an EDITOR ONLY check. Hope this helps.

I never said CI/CLI anywhere in my comment, having it fail in editor is problematic enough.

@dmsch
Copy link

dmsch commented Aug 9, 2023

This project appears to be in violation of GDPR by sending hashed email addresses to a foreign server, allowing for user tracking. The use of obfuscated code further raises concerns about the project’s transparency and intentions. Therefore, we classify this package as malware.

@kzu
Copy link
Contributor

kzu commented Aug 9, 2023

Would making the SL source code OSS too, dissipate the concerns? Seems like checking the sponsoring might still be an issue even in that case?

@rokonec
Copy link

rokonec commented Aug 9, 2023

Seems like checking the sponsoring might still be an issue even in that case?

Well, big part of my work is optimizing build performance and such. Seeing things like
image
is unacceptable behavior.
So yes, in my books, this kind of sponsorship extorsion will be an issue even if open sourced.

@sbergot
Copy link

sbergot commented Aug 9, 2023

Would making the SL source code OSS too, dissipate the concerns? Seems like checking the sponsoring might still be an issue even in that case?

Making the code open source would not make it ok from a GDPR point of view. It would just improve the perceived intention. The only way to make it ok for GDPR is to state which data is being collected for which usage and ask for user consent. And it has to be done with a specific legal framework.

edit: @kzu as other have said, you are now exposed to litigation. I would urge you to remove the 4.20.x versions just to limit the legal risk. It would only take one vindicative organisation to make things worse for you.

@steve-fenton-octopus
Copy link

To expand on the answer to the GDPR question, if you create an identifier that can be used to identify an individual and link them to other data it is classed as PII. If you are collecting your email-hash from users in the EU you are definitely collecting personal data that requires specific informed consent.

There is zero chance of claiming legitimate interest for this processing and even if you did, you have to provide a mechanism to allow users to object to processing and exercise their rights.

https://commission.europa.eu/law/law-topic/data-protection/data-protection-eu_en

@michalrosenbaum
Copy link

michalrosenbaum commented Aug 9, 2023

You can compare those hashes against set of mails leaked somewhere else and this way identify me. Even hashed mail should be sent only after consent.

@fuglesang
Copy link

From the readme:

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

The statement that this can "never reveal the originating email" is wrong. As mentioned earlier, what this hashing achieves is considered to be pseudonymization.

Pseudonymized data can be restored to its original state with the addition of information which allows individuals to be re-identified.

By using, for instance, a rainbow table one can restore the original data.

GDPR Recital 26 explains

...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.

@Mart-Bogdan
Copy link

I can't understand why the hell it is closed sourced AND obfuscated!

@madhon
Copy link

madhon commented Aug 9, 2023

To expand on the answer to the GDPR question, if you create an identifier that can be used to identify an individual and link them to other data it is classed as PII. If you are collecting your email-hash from users in the EU you are definitely collecting personal data that requires specific informed consent.

There is zero chance of claiming legitimate interest for this processing and even if you did, you have to provide a mechanism to allow users to object to processing and exercise their rights.

https://commission.europa.eu/law/law-topic/data-protection/data-protection-eu_en

Also SHA256 has been rejected by court already as not sufficient to hash emails
https://www.spiritlegal.com/en/news/details/e-commerce-retail-facebook-custom-audience-not-allowed-without-consent.html

"The court found that the SHA-256 hashing procedure used was not suitable for assuming anonymisation of personal data within the meaning of Section 3(6) of the old version of the German Federal Data Protection Act (hereinafter referred to as the “old BDSG”). Despite the creation of hash values prior to the transfer as a decisive processing step (Section 3(4) Sentence 2 No. 3 old BDSG), it was deemed possible to re-identify data subjects with not only disproportionate effort. Otherwise, Facebook would not be able to compare the data after the transfer."

@madhon
Copy link

madhon commented Aug 9, 2023

I can't understand why the hell it is closed sourced AND obfuscated!

To hide it, nothing more.

@wdolek
Copy link

wdolek commented Aug 10, 2023

My 2¢: After the issues we faced recently, I think it's time to think carefully about this project's future.

Even if we were to fix the problem with the closed-source library being injected into any project (#9) by making it open for everyone to see, and even if we made sure the dotnet analyzer doesn't make any unexpected web connections (#10), I'm still not sure that would be enough.

While the concept of GUIDs stored on a developer's PC has been suggested (@kzu mentioned this idea yesterday), it does not appear to be a comprehensive solution of balancing company sponsorship against individual employed developers' use of the library (additional details would be helpful in understanding this proposal).

I genuinely understand and appreciate the need for corporate support the FOSS community, and the critical role that it plays in enabling maintainers to contribute without financial constraints. However, I believe it's important to ensure that the path you (we, community) take aligns with our shared values and principles. Several successful models for fostering collaboration within the open-source community were mentioned at https://github.com/moq/moq/issues/1374.

@madhon
Copy link

madhon commented Aug 10, 2023

Hi @DanielCordell , thanks for sharing your concerns. No CI/CLI builds will ever fail since those checks are never performed in those scenarios.

This is an EDITOR ONLY check. Hope this helps.

The fact that it breaks on MacOS and Linux, which use the command line to build suggests your assertion is wrong.

Open the source, prove us wrong, until then there is no trust around this at all.

@ABruel
Copy link

ABruel commented Aug 10, 2023

Seems like checking the sponsoring might still be an issue even in that case?

Well, big part of my work is optimizing build performance and such. Seeing things like image is unacceptable behavior. So yes, in my books, this kind of sponsorship extorsion will be an issue even if open sourced.

Wait, this thing blocks the build for 130ms if you aren't sponsoring a library that uses it? Now that's gold.

@madhon
Copy link

madhon commented Aug 10, 2023

There's also that any builds with warnings as errors will fail to build

@kzu
Copy link
Contributor

kzu commented Aug 10, 2023

I do think build pauses for non-sponsors is an acceptable trade-off for library authors who want to get sponsored for their work. Please chime in on #33 . Closing this to we keep discussions separate on the various issues raised.

@kzu kzu closed this as completed Aug 10, 2023
@FeldrinH
Copy link

FeldrinH commented Aug 10, 2023

Please chime in on #33 . Closing this to we keep discussions separate on the various issues raised.

But the original issue here and #33 are completely unrelated? The original issue here is that SponsorLink as currently implemented is likely to violate a lot of corporate guidelines for what dependencies can be used (due to being obfuscated and the source not having an open source license), which has nothing to do with the build pauses.

@TsengSR
Copy link

TsengSR commented Aug 10, 2023

I do think build pauses for non-sponsors is an acceptable trade-off for library authors who want to get sponsored for their work. Please chime in on #33 . Closing this to we keep discussions separate on the various issues raised.

No it's not. Everyone understands your need for compensation for the work done, but for gods sake, offer commercial support (in the form of SLA) or trainings.

This brings way more value to the companies to know that they can ask for a critical bug fixed or new feature added, who would be more willing to pay to have this kind of guarantees. That would bring you way more than a few bucks charity, something you could even build a whole business model on it. The whole goddamn Linux ecosystem works on this premise and employs thousands.

Your way resembles more of a blackmailing approach or the "chip out" way, get as much money possible then quit and abandon it. If anything, you reached the opposite of what you wanted. Not only that, but you are at very high risk of getting sued by a few 10's of dollars per case for violating GDPR and the damage you caused, if the companies would decide to sue you (the GDPR is not up to the companies its to the users and the GDPR authorities) because they now have to remove your malware from their projects which may be weeks and months worth of work to rewrite all the tests to work with a different mocking framework!

@devlooped devlooped locked as off-topic and limited conversation to collaborators Aug 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests